The Bulge SOP was made to work with metaballs.
If you just want to 'shape' by attribute alone you could do what I have in the hip.
Found 2033 posts.
Search results Show results as topic list.
Technical Discussion » Bulge on attribute ?
- BabaJ
- 2035 posts
- Offline
Houdini Indie and Apprentice » Trace node producing jagged edges and weird normals
- BabaJ
- 2035 posts
- Offline
For your 'problem #1" the 'issue' is that you are using a png so it is a 'raster' image with anti-alising of the pixels to give the appearance of a smooth edge.(There's no parametric information defining the shape. The appearance of the 'edge' is created by 'dimming' pixels from view, for a 'blurring' effect, but the pixels themselves still form a step-wise/jagged pattern).
So there is no actual 'smooth edge'(parametric) to trace/duplicate - It's being done algorithmically by the trace node to get as close as possible; To what an actual smooth edge might be.
If your imput geometry was vector based - like an *.igs file format, then you could have a better source to work from.
However, if you adjust the trace nodes step parameter and follow the trace node after with a smooth node and set that node parameter 'Constrained Boundary' to none, the method parameter to 'Curvature Dominant' and then adjust the Strength and Filter parameters, you should be able to get a better working result.
So there is no actual 'smooth edge'(parametric) to trace/duplicate - It's being done algorithmically by the trace node to get as close as possible; To what an actual smooth edge might be.
If your imput geometry was vector based - like an *.igs file format, then you could have a better source to work from.
However, if you adjust the trace nodes step parameter and follow the trace node after with a smooth node and set that node parameter 'Constrained Boundary' to none, the method parameter to 'Curvature Dominant' and then adjust the Strength and Filter parameters, you should be able to get a better working result.
Edited by BabaJ - April 15, 2024 13:03:37
Technical Discussion » Why are there no surface generated from rail node?
- BabaJ
- 2035 posts
- Offline
Houdini Lounge » HOUDINI 20 INSTABILITY
- BabaJ
- 2035 posts
- Offline
alexeyvanzhula1984Never said they didn't.
Many people (including developers when sending RFE) have already confirmed this error
You asked, and I replied I don't.
Houdini Lounge » HOUDINI 20 INSTABILITY
- BabaJ
- 2035 posts
- Offline
alexeyvanzhula1984
1. select face
2. press T
3. Press Sapcebar
4. Press Escape
After this, do you really not see any errors?
No, I don't.
Technical Discussion » How to get rid of new vertices by subtraction Boolean ?
- BabaJ
- 2035 posts
- Offline
Subutai
Almost, the bottom vertices still seem to be present.
That's because of your input geometry.
Try cleaning it up first. You have double prims.
Edited by BabaJ - April 13, 2024 13:02:26
Technical Discussion » How to get rid of new vertices by subtraction Boolean ?
- BabaJ
- 2035 posts
- Offline
Houdini Lounge » HOUDINI 20 INSTABILITY
- BabaJ
- 2035 posts
- Offline
Technical Discussion » How can the parameter be called in wrangler?
- BabaJ
- 2035 posts
- Offline
float diff_x = vector(detail(0,'table_dimmin')).y;
You were treating detail as if it was an HScript function.
Technical Discussion » Karma Physical Sky issue
- BabaJ
- 2035 posts
- Offline
It's not a bug or limitation.
It's using the Flat Earth model - so working as intended.
It's using the Flat Earth model - so working as intended.
Houdini Indie and Apprentice » Toruses copied to points fall as one object in RBD sim
- BabaJ
- 2035 posts
- Offline
I separated your toruses and merged them one by one in the merge node for the rigid body solver so it treats the objects separately.
I haven't used these solvers in a long time, so keep your eyes peeled for this thread in case someone with more experience knows a better more efficient way.
I haven't used these solvers in a long time, so keep your eyes peeled for this thread in case someone with more experience knows a better more efficient way.
Technical Discussion » Scale Geometry Inwards
- BabaJ
- 2035 posts
- Offline
TheDude123
If you zero-out the translate on the transform1 node (sending the piece back to it's original position), and take a look at the vertical part in the middle, the geo doesn't really scale inwards like the rest
It does scale equally inward like the 'rest'.
The 'vertical' part is about the x center of the pivot. So when you 'zero out' like you say it comes back to world center.
Just look at the 'vertical' part in relation to either side of the geo ends - both are scaled down in relation to each other.
If you don't like the vertical part to seem stationary, shift your object to either side of world center - It will still be uniformly scaled down in all directions.
It's not that it isn't scaling down uniformly - It's because you are assuming it should look a certain way, when it won't.
Look at the merge node in the file in wireframe mode so you can see the two together, the original and the scaled down but moved to a different position in relation to the original - Each side is proportionaly smaller to the same degree of the original.
".it just kinda stays in place"....so just have the scaled object translated to another position.
Also in your original post, the second image you have in which you think it is being scaled evenly, when it is not.
Look at the left hand side edge in your image, before and after - It becomes smaller. But look at your vertical edge in the 'middle', before and after - It stays the same size before and after.
So in your second image it does not get scaled down evenly. What does happen evenly is that it is offset evenly(distance is even from original).
If it's an even offset that you want - you have to decide what parts of your geometry you are going to omit/cut.(if you want the rough faces on each side of your geometry to have the same uniform polyface sizes of one side compared to those of the other.
Edited by BabaJ - March 25, 2024 09:44:28
Technical Discussion » Scale Geometry Inwards
- BabaJ
- 2035 posts
- Offline
but the centroid method does not produce the results I'm looking for.
You should be able use any arbitrary pivot position other than just the centroid.
In this hip I've just set up a range of possible positions - you don't have to lay down as many nodes as I have.
I just did this to show there are a number of pivot positions that could give satisfactory results.
It's just a matter of choosing a position in which the direction of scaling will keep unwanted 'distortions' at a minimum or not at all(which is possible).
Edited by BabaJ - March 24, 2024 15:39:44
Technical Discussion » How to offset the whole motion path?
- BabaJ
- 2035 posts
- Offline
Provide the hip that shows how you have implemented the motion path to begin with?
There can be more than one way, and as a result more than one way to offset.
Otherwise at face value, a simple transform node of the geometry that is having the motion applied too would work.
There can be more than one way, and as a result more than one way to offset.
Otherwise at face value, a simple transform node of the geometry that is having the motion applied too would work.
Edited by BabaJ - March 20, 2024 08:50:41
Technical Discussion » Keyframe Values Within ForEach with FeedBack
- BabaJ
- 2035 posts
- Offline
tamte
why would it assume such convoluted use case as starting at frame 1 and increase number of iterations per frame and override internal time based on iteration ?
It's only convoluted because you're still thinking in terms of the current context of how it works.
And there would be no increase number of iterations per frame.
The block of begin/end nodes can be a self contained unit of code that is run.
tamte
Then you'd want a way to override that behavior and being able to sample some curves at global frame
Yes of course, that's what I was saying - It could 'override'.
The end or beginning block could look at what is driving the count - and if a $F or similar trigger is present run the block of code/nodes within the 'loop' as time dependant for those places in which Keyframes are detected. So instead of sampling per frame, sampling occurs per loop count.
Another way, but more flexible is to have a multi-parm list in which the user decides which if any node/parameter that has a Keyframe to be sampled per loop specifically, while others(Keyframed parameters) could retain their default behavior linked to frames progressing.
It could also have a switch for turning it to per Frame mode(instead of detecting $F as before).
In such a mode along with Fetch Feedback, then the loop block does all the work per iteration/frame and retains memory of what was done for the next frame/ Instead of iterations increasing per frames progressing.
it could but why would it do that?For greater flexibility and a block loop of code that behaves more like an actual loop - Thereby freeing up the end user to focus more on the logic of what they are doing instead of keeping in mind how it actually works. Being more akin to how loops in code are written and can be utilized when working with data.
Edited by BabaJ - March 20, 2024 08:43:34
Technical Discussion » Keyframe Values Within ForEach with FeedBack
- BabaJ
- 2035 posts
- Offline
tamte
Foreach loop doesn't have concept of time
Yes this is true. And that is the crux of the matter that got my attention.
It doesn't, but it could - Since all the information is available to do so.
But I'm certainly not going to put in an RFE for such as I can't think of any need,
and like you said - a SOP solver is already available to take care of previous frame data.
Technical Discussion » Keyframe Values Within ForEach with FeedBack
- BabaJ
- 2035 posts
- Offline
tamte
with your keyframed method you are just animating the translate, so each frame the forloop does all the iterations with the same value of the current frame
Yes and that's 'interesting'.
Because at face value - in both cases, one gets a unique and expected value in the transform parameter;
Meaning both the expression and 'animated' values change/progressively about the same for each loop.
One just has to swtich to Single Pass mode to inspect and see that the values change uniquely for each loop.
It's like the for each loop won't 'disconnect' the source of the parameter values(in this case the animation driven ones) and just go with the actual parameter values on a per loop basis - even though the information to do that is all there, I.E. established static bezier curve, Frame Number to get value at specific point of bezier, Number of Loops.
tamteIndeed, the actual original example was with a SOP Solver, I was interested in looking at trying things differently for curiosities sake.
be more efficient with Solver SOP instead
Edited by BabaJ - March 19, 2024 19:35:24
Technical Discussion » Keyframe Values Within ForEach with FeedBack
- BabaJ
- 2035 posts
- Offline
I was looking at some forum examples and playing around with doing them differently.
I don't use keyframes in my work, so when I tried modifiying an example that had keyframes I was puzzled as to why it was not working as expected in a foreach loop with feedback.
When I do an equivalent with an expression it does work as expected.
The for each loop is doing a cumalative boolean on geometry that gets fedback, being translated each time.(for each loop).
The values of the keyframed driven translation do apply to the intersecting geometry, but the feedback loop does not feedback the boolean results - Only on a per loop basis.
The expression driven one does both, again, giving the expected result.
In the hip file there is a switch node that can select and see the comparable results.
I don't use keyframes in my work, so when I tried modifiying an example that had keyframes I was puzzled as to why it was not working as expected in a foreach loop with feedback.
When I do an equivalent with an expression it does work as expected.
The for each loop is doing a cumalative boolean on geometry that gets fedback, being translated each time.(for each loop).
The values of the keyframed driven translation do apply to the intersecting geometry, but the feedback loop does not feedback the boolean results - Only on a per loop basis.
The expression driven one does both, again, giving the expected result.
In the hip file there is a switch node that can select and see the comparable results.
Edited by BabaJ - March 19, 2024 18:04:35
Technical Discussion » What is the difference between =set() and ={}
- BabaJ
- 2035 posts
- Offline
tamteIt is VEX in terms of the context it was presented. That's why I put 'detail' as I did in quotes, so it would be understood as that.
@ binding is not part of VEX,
I was looking at that code box (VEX) and how the various elements that could be used in such a code box, ends up getting treated/processed.
tamteIt most definitely did.
My post meant just to expand
tamteYes that certainly was made clear.
clarify more why that's not allowed
However, my leaning was towards looking at where/how that happens in the pre-compiler/compiler process(or some other sequence of processing). The process that takes everything in the code box (In a broader context of the meaning of vex, the starting point of the code written in that 'vex' box)and how it handles the various elements and at what stage/s.
Just to add to the conversation again in reference to other code that's already been posted:
This works
#define Example_A set(5) #define Example_B {3,5,6} #define Example_C 10.2 * 5
But you could not add another line of code(to the previous code) doing this
Example_B += 2;
But you can do this
int @Att_Example = 5; @Att_Example += 2;
But you can not do this
int @Att_Example = set(5); @Att_Example += 2;
Because of these difference, local 'variable' and 'attribute' - there's going to be different scenarios where one can or cannot be using something like set() or {}
Edited by BabaJ - March 18, 2024 17:06:29
Technical Discussion » What is the difference between =set() and ={}
- BabaJ
- 2035 posts
- Offline
tamteIt wasn't meant to imply in only detail set wrangle, it was only meant to inform of the context the points being made are from.
that's not allowed in any wrangle,
tamteWhich is what I was saying - the function set() is a computation.
since that's the default value for the prototype and that has to be constant
tamteIt's 100% a vex thing in terms of how the compiler/pre-compiler or even some special 'stage' of processing; Which takes into account 'attributes' as defined uniquely in Houdini with the '@'
it's not necessarily a VEX thing, it is the snippet syntax, but because it translates to the CVEX shader argument, it can't contain anything else than literal constants
As my example already showed, simple variables get treated differently; As a result, at whatever stage, they are dealt with differently.
tamte
just note that defining the prototype with default constant value:
vector @up = {2,0,5};
is a different thing from assigning a value to the attribute:
v@up = {2,0,5};
where you can use variables and any sort of runtime expressions
v@up = set(a,0,5) * 2;
Yes, it wasn't about the defining of a prototype per se, but the fact that we have two different elements being dealt with(on the point being made) - local varaibles, and attributes - both at some point in the pre-process/compilation stage/s are treated and looked at differently.
-
- Quick Links