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.
Found 2040 posts.
Search results Show results as topic list.
Technical Discussion » How to offset the whole motion path?
- BabaJ
- 2042 posts
- Offline
Technical Discussion » Keyframe Values Within ForEach with FeedBack
- BabaJ
- 2042 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
- 2042 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
- 2042 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
- 2042 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
- 2042 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
- 2042 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.
Technical Discussion » What is the difference between =set() and ={}
- BabaJ
- 2042 posts
- Offline
ObeidaZakzak
When working with static values, curly braces {} are preferred as they do compile-time evaluation.
Which brings up some interesting observations that is likely related to what you said, but not just compile-time, but pre-process compilation stage?, and also the 'added' element of Houdini in which attributes are used and how they are treated; vex being not just dealing with local variables.
In a 'detail' wrangle this is allowed:
vector @up = {2,0,5};
This is not:
vector @up = set(2,0,5);
But this is:
vector up = set(2,0,5);
And this is not:
vector @up = {2,0,5} * 2;
Edited by BabaJ - March 17, 2024 14:23:14
Technical Discussion » Different result for the same 'rand(1)' expression
- BabaJ
- 2042 posts
- Offline
Likely because they are two different functions - Only the same in name.
One is an Hscript function the other vex.
My Guess - The Hscript one has been around for a long time before the vex context came along.
But when they wrote the rand function for vex, I think they made some decisions/considerations about that to 'work better' in a vex context. Being that both functions purpose is to produce a random result - I don't think they 'felt' the need and try to keep the results the same for same seed values.
If you do need some consistency between both contexts, you should be able to go with one rand() in one context and simply reference the result for another context.
One is an Hscript function the other vex.
My Guess - The Hscript one has been around for a long time before the vex context came along.
But when they wrote the rand function for vex, I think they made some decisions/considerations about that to 'work better' in a vex context. Being that both functions purpose is to produce a random result - I don't think they 'felt' the need and try to keep the results the same for same seed values.
If you do need some consistency between both contexts, you should be able to go with one rand() in one context and simply reference the result for another context.
Edited by BabaJ - March 15, 2024 13:00:25
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- BabaJ
- 2042 posts
- Offline
vertexbend
Are the developers intentionally making it more difficult to work in this program with each new release?
No, they aren't.
What is this concept of working with materials where, in order to simply assign a material to an object, you need to go Google?
The concept is yours; And a good one. If you don't know how to do something, yeah searching google or looking at tutorials is a good concept.
What do developers achieve with this attitude towards users?But it's your attitude, not the developers; And the result is you get to learn.
Why in Houdini does nothing ever work by default in the best, obvious way?
There's a difference between working by default and working by how you want it set up.
There is also a difference between what is obvious for you and what is obvious for others.
How you like to work is not the same as how others would like to work; So 'obvious' will be different for each person.
So essentialy, except for bugs, everything does work by default in Houdini, contrary to your statement.
Why do you always need to look for some kind of checkbox to invert, activate, switch, etc.? WHY???
So you can work with Houdini the way you want to and others can work with it the way they want too.
Are developers really that indifferent to their users?
No, but you are being 'indifferent' to how others like to use Houdini.
But who are they developing this program for then?
For people who find Houdini usefull.
This work with materials in Karma, where it is impossible to assign a material to an object, is some kind of Karma..
Actually, it's not impossible; that's my experience at least.
Edited by BabaJ - March 14, 2024 12:05:39
Houdini Lounge » What do you guys think about sora?
- BabaJ
- 2042 posts
- Offline
Sygnum
How do you compete against a machine which generates more and more art directable output within minutes
That's easy to 'compete' with AI.
'You' use AI like a tool.
Current research(sorry I didn't keep a link for that study) shows AI by it's nature, is convergent rather than divergent.
And the reason it is like this is because it is basically a massive data aggregator - bascially 'looping' in on the very data set it refers to; On itself.
In order to become divergent it needs new data/information that lies outside of itself - Which only something that is Conscious can do, that has the capacity for originality - Humans.
Houdini Indie and Apprentice » Group by @Cd
- BabaJ
- 2042 posts
- Offline
eikonoklastes
It was to prevent the app from literally freezing when you use the most common slider on one of the most common nodes. That's just bad UI/UX design and needs to be fixed.
As stated before - a gaurd is already available. Use the bypass flag.
Houdini Indie and Apprentice » Group by @Cd
- BabaJ
- 2042 posts
- Offline
Mike_A
I'm sure I've put in an RFE requesting some form of a guard against this.
Hopefully such an RFE doesn't materialize. Creating 'guards' like this begins to make the process cumbersome to allways have to untick/remove a default gaurd before using the node, when one is already familiar with their workflow and node usage.
Houdini already has a default process that can be used as a gaurd for all nodes.
When laying down a node and you are not sure of the 'consequences' beforehand, before wiring it up set the bypass flag(yellow one furthest to the left on a node), wire it up.
Then look at your parameter settings and make adjustments so you are sure it's not going to set a 'run away' process.
Then just unset your bypass flag.
Houdini Indie and Apprentice » Export Simple Curve from Rhino to Houdini
- BabaJ
- 2042 posts
- Offline
When I need to import from Rhino...I will export from Rhino as .obj if I simply want 'polygon surfaces'.
If I want nurbs/bezier curves etc. I export as .igs
If I want nurbs/bezier curves etc. I export as .igs
Technical Discussion » Offset Attribute Value in time
- BabaJ
- 2042 posts
- Offline
You can do chops then and only address specific parameters/channels.
In this example I was able to directly feedback into the foo parameter with some re-cooking to clear the infinite recursion,
but it's probably not a good idea, so in this example foo is in the previous node and the chop re-time or stretch is having the export directed to the next node as scale.
In this example I was able to directly feedback into the foo parameter with some re-cooking to clear the infinite recursion,
but it's probably not a good idea, so in this example foo is in the previous node and the chop re-time or stretch is having the export directed to the next node as scale.
Edited by BabaJ - Jan. 13, 2024 11:22:51
Houdini Lounge » Noise level for animation and use of denoiser
- BabaJ
- 2042 posts
- Offline
I'm not experienced in animation/production work - but likely experience is the number one factor; and I would suspect a number of test renders at key points which only cover a short range of the animation but if 'succesful' in giving the results desired is indicative of other areas being the same that have similar content processed.
Technical Discussion » Offset Attribute Value in time
- BabaJ
- 2042 posts
- Offline
If I understand you right, you should be able to easily do what you want with the time warp node, using the 'Input Frame Range' parameter to equate your bezier parameter function start and end frames - Then define the 'Output Frame Range' to either shift the start and end times somewhere else or stretch(1-48 rather than 1-24 for example)or even both shift and stretch.
Technical Discussion » Vex spline(): how to specify bezier curve control points?
- BabaJ
- 2042 posts
- Offline
There's many ways to use the spline function, just need to look at the arguments of the function and see the relationship between the arguments of the function.
In this file the the second argument 'sample_pos' determines the resolution of the curve, the higher the number the smoother it gets with the conversion to polyline.(Houdini doesn't give a direct viewable spline through vex - like what you would get with the curve sop).
The other arguments:
vector SH = chv("start_handle");
vector EH = chv("end_handle");
vector Pt1 = chv("start_pt_position");
vector Pt2 = chv("end_pt_position");
Show the order(within the function) and their effect on the curve.
In this file the the second argument 'sample_pos' determines the resolution of the curve, the higher the number the smoother it gets with the conversion to polyline.(Houdini doesn't give a direct viewable spline through vex - like what you would get with the curve sop).
The other arguments:
vector SH = chv("start_handle");
vector EH = chv("end_handle");
vector Pt1 = chv("start_pt_position");
vector Pt2 = chv("end_pt_position");
Show the order(within the function) and their effect on the curve.
Houdini Lounge » I've been badly cheated. Houdini is a programmer's world.
- BabaJ
- 2042 posts
- Offline
It's not true in the last instance.It is true - Companies don't have infinite resources.
Developer's resources are spent on common (general) high-level tools
And they are also spent on 'low level' aspects of the program.
Again, since you made the following statement initially, of which I already responded in that context...
"The message needs to be conveyed to the developer that Houdini's tools need to be more high-level so that the artist remains an artist, rather than turning into a programmer."
That's a suggestion of directing more resource/time towards your preferences; Of which, IF it takes away too much time from lower level(compared to your suggestion/s)development; I'm not in favor of that direction.
Edited by BabaJ - Dec. 31, 2023 13:14:07
Houdini Lounge » I've been badly cheated. Houdini is a programmer's world.
- BabaJ
- 2042 posts
- Offline
tamte
so I don't see how high level tools get in a way of the underlaying framework
In of itself it doesn't.
But it does matter if too much time is spent on high level tools. No company has infinite resources to spend on development to suit everyone.
So no, the thinking isn't flawed and the point being presented wasn't about an either or situation. It was about where the emphasis on development should be, continue to be.
We are talking about SideFX here, they will never dumb their software down to just high level blackboxesCertainly with the current CEO and staff at SideFX, you're right.
But 'never' is a very long time.
People eventually retire/die, etc. There's always the chance SideFx gets sold and takes a turn in a very new direction, potentially ignoring the current user base at that time altogether. Again, never is a very long time.
Edited by BabaJ - Dec. 31, 2023 11:49:33
-
- Quick Links