In my asset I want to mimic rig pose output by calling transform functions in vex. I followed matrix multiplication orders mentioned in the rig pose documentation. but results are not same. even for pre-multiply mode which should not have need any special treatments there is some transform shift.
what's the problem?
as a test case and for simplicity, attached file code, works on point 0 and 2 of the chain.
I struggled badly here. any help would be greatly appreciated.
Found 49 posts.
Search results Show results as topic list.
Technical Discussion » Unmatched vex transform output compared to rig pose output
- sorian
- 49 posts
- Offline
Technical Discussion » Getting the Falling Ball Control with the Hard Constraint
- sorian
- 49 posts
- Offline
Technical Discussion » Getting the Falling Ball Control with the Hard Constraint
- sorian
- 49 posts
- Offline
Hard constraint's both points there are at same position.
the ball is falling and after some frames of simulation hard constraint wants to handle the ball movement with respect to the happened constraint to ball offset at switch time.
how can i do this in a smooth way without any ball jumping and hard constraint length change at switch time?
Seems hard constraint considers just initial SOP level offset to the ball not simulated one, for its internal calculations which causes jumpy transition and after a couple of frames it ignores the ball's simulated offset completely.
Initial scene setup in the attachment.
the ball is falling and after some frames of simulation hard constraint wants to handle the ball movement with respect to the happened constraint to ball offset at switch time.
how can i do this in a smooth way without any ball jumping and hard constraint length change at switch time?
Seems hard constraint considers just initial SOP level offset to the ball not simulated one, for its internal calculations which causes jumpy transition and after a couple of frames it ignores the ball's simulated offset completely.
Initial scene setup in the attachment.
Edited by sorian - July 26, 2020 20:47:50
Technical Discussion » breaking for loop sop enclosed inside compile sops
- sorian
- 49 posts
- Offline
In addition to what has been said Tomas, your last paragraph actually describes what i was thinking about too. putting a huge network inside just a single compile block, for maximum versatility instead of patching a bunch of compile blocks as a hack way to overcome this For loops limitation which is suffering from some major performance issues. having a huge network means having lots of loops. developers write software and hit compile once to get the executable binary.
Technical Discussion » breaking for loop sop enclosed inside compile sops
- sorian
- 49 posts
- Offline
Good news. because what i am working on now, highly depends to this functionality. so i can continue my work by some considerations, till updates.
Technical Discussion » breaking for loop sop enclosed inside compile sops
- sorian
- 49 posts
- Offline
thanks @jlait
I want to reach to an specified number of points for varied geometries with varied number of points as inputs to the loop and inside the loop also just a chunk of the input geometry gets isolated according to some criteria as the input of the delete SOP (unknown number of points). so we need to count number of points of delete SOP in every iteration to check we reached that specific number of points or not. obviously filling spare input by the nodes placed inside the loop causes errors and as you know makes your trick unused. so no real resembling of stop condition.
And regarding the problem of being unclear, if spare inputs to a for end block should be evaluated before or during the for loop, could not be a solution to give us a control to decide manually which one should be performed depending on the pros and cons of each, in different scenarios? for example in our simple test scene, we are aware that delete SOP surely placed inside the loop chain.
Anyway, will this be a persistent architectural limitation of compile SOPs or will be removed in future builds or versions of Houdini? it prevents (limits) us to benefit from one of the main advantages of using compile blocks. multithreaded while (for) loops for processing networks which are dealing with heavy geometry sets, without a pre-known end number of iterations.
I want to reach to an specified number of points for varied geometries with varied number of points as inputs to the loop and inside the loop also just a chunk of the input geometry gets isolated according to some criteria as the input of the delete SOP (unknown number of points). so we need to count number of points of delete SOP in every iteration to check we reached that specific number of points or not. obviously filling spare input by the nodes placed inside the loop causes errors and as you know makes your trick unused. so no real resembling of stop condition.
And regarding the problem of being unclear, if spare inputs to a for end block should be evaluated before or during the for loop, could not be a solution to give us a control to decide manually which one should be performed depending on the pros and cons of each, in different scenarios? for example in our simple test scene, we are aware that delete SOP surely placed inside the loop chain.
Anyway, will this be a persistent architectural limitation of compile SOPs or will be removed in future builds or versions of Houdini? it prevents (limits) us to benefit from one of the main advantages of using compile blocks. multithreaded while (for) loops for processing networks which are dealing with heavy geometry sets, without a pre-known end number of iterations.
Edited by sorian - March 17, 2017 19:24:23
Technical Discussion » breaking for loop sop enclosed inside compile sops
- sorian
- 49 posts
- Offline
hi @ndickson
unfortunately i am not successful to upload the HIP file. after attaching the file and hitting the submit button, attached is not uploaded, just text.
here i describe a very much simple setup i had.
1. put down a box
2. create a for loop (iteration method: By Count)
3. inside the loop put down a delete sop (Entity: Points, Pattern: 0)
4. in for loop block end (Stop Condition: npoints( ‘../delete1’) < 5)
5. construct another version of above steps, but this time inside a compile block.
actually in every loop iteration we want to delete one more point of the incoming box, until we reach to 5 points.
increase the ‘Iterations’ parameter in each ‘block end’s to see the difference.
unfortunately i am not successful to upload the HIP file. after attaching the file and hitting the submit button, attached is not uploaded, just text.
here i describe a very much simple setup i had.
1. put down a box
2. create a for loop (iteration method: By Count)
3. inside the loop put down a delete sop (Entity: Points, Pattern: 0)
4. in for loop block end (Stop Condition: npoints( ‘../delete1’) < 5)
5. construct another version of above steps, but this time inside a compile block.
actually in every loop iteration we want to delete one more point of the incoming box, until we reach to 5 points.
increase the ‘Iterations’ parameter in each ‘block end’s to see the difference.
Technical Discussion » breaking for loop sop enclosed inside compile sops
- sorian
- 49 posts
- Offline
does anyone know a way to break a for loop sop which is enclosed inside of compile sops?
seems compile sops ignore the expression written inside ‘stop condition’ parameter in for loop's ‘block end’, and may be expressions in overall.
seems compile sops ignore the expression written inside ‘stop condition’ parameter in for loop's ‘block end’, and may be expressions in overall.
Edited by sorian - March 17, 2017 06:04:06
Houdini Lounge » Houdini Roadmap video
- sorian
- 49 posts
- Offline
It would be nice if new icons' separated inputs and output dots, support dynamic positioning of themselves around the icon's main shape.
so we would be able, for our biped character, to sort out vertically spine bones with standard connection ports placement, and horizontally hand bones with connection ports placed at left and right side of the operator.
even it would be nicer if we have the ability for scaling and rotating of the icon's main shape.
so spine bones icons' main shape, will being rotated 90 degrees to emphasize more, spine bones placement is vertical.
Seems now i am looking to the network editor as a painting canvas
so we would be able, for our biped character, to sort out vertically spine bones with standard connection ports placement, and horizontally hand bones with connection ports placed at left and right side of the operator.
even it would be nicer if we have the ability for scaling and rotating of the icon's main shape.
so spine bones icons' main shape, will being rotated 90 degrees to emphasize more, spine bones placement is vertical.
Seems now i am looking to the network editor as a painting canvas
Work in Progress » C++ Wrangle: The Last Frontier In Custom Tool Development From Within Houdini
- sorian
- 49 posts
- Offline
I think tools like this and your OpenCL Wrangle SOP that harness and empower Houdini dramatically for TD works, do not need so much community requests for being addressed. SESI should be enough wise for addressing these as Houdini new features, which they are
and congratulations @pusat.
you have done some great jobs.
and congratulations @pusat.
you have done some great jobs.
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
i'm not a SI user, so i put this in the “Lounge” section.
i can not find relation of the thread title and not respecting to the highly talented respectful people around here. these are completely two different subjects.
do you want we suppose houdini has always been most complete package in all fields from the beginning without any need for any improvement and any discussion?
also admin can change the thread title if it doesn't obey from the forums rules.
i can not find relation of the thread title and not respecting to the highly talented respectful people around here. these are completely two different subjects.
do you want we suppose houdini has always been most complete package in all fields from the beginning without any need for any improvement and any discussion?
also admin can change the thread title if it doesn't obey from the forums rules.
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
MartybNz
Can I ask …
i am in the middle of preparing a list of RFEs for support beside these three, not two (1.add floating point key … 2.scaling keys … 3. tuner(retimer) tool …) if i find enough time to finish.
some of them need some considerations to be pretty understandable for the devs, also to be clear for me they are certainly bugs.
meantime, posting to support doesn't prevent replying to people in the forum.
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
Jim Rutherford
Call me old fashioned.
veterans come from old fashioned people. we always respect them
Jim Rutherford
but good planning, …
sometimes we need importing a good planned pose to pose animation clip from our library, bake it for concatenating to another good planed pose to pose animation, now think about some more iteration of this process, and plus some overall editing of them to satisfy that specific shot needs till to get unique.
just think about that our run cycle continuation, in a long run must be matched to a curved path (no straight running) and without any foot sliding on the ground, plus some additional clips attached to it.
you see, we are getting forced to go toward doing that damn straight ahead animation lightly, so unfortunately we all get heebie jeebies sometimes
indeed @Jim, having something better never doesn't hurt anybody. :wink:
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
Jim Rutherford
but…really, animating like that in the timeline?
Yes @Jim. simply because of performance.
keyframes graphical representation in the timeline benefits from a simpler representation than in the animation editor.
in a production class environment (read feature film quality animation), animators dealing with tens of channels and hundreds of keyframes at the same time. that rich representation of splines, handles and … in the animation editor causes computationally overheads when the number of scoped channels increases. so it happens many times, overall keyframe positioning being down in the timeline which is not just limited to first stage roughing, rather can happen many times in a work day, and then dealing with a limited number of channels in the animation editor for more local editing.
if maya benefits from another editor for handling animation data, that is named “trax editor”, it is another level of simplification than even timeline for showing animation data, which boosts the performance. here we see a bunch of keyframes that the number of them can be hundreds just as a stretchable box (a clip) in the trax editor (beside the main duty of this editor that is the non linear editing)
actually true answer to this question is a combination. a consecutive usage of animation editor and timeline.
not just setting keyframes in the timeline at first stage and then dealing with keys afterward in the animation editor forever, without going back to the timeline.
if i suggested implementation of a timeline version of tuner (retimer) in the first post attached picture, actually it is implying to this fact:
PERFORMANCE INCREASE when dealing with tens of dense fcurves for easier overall retiming of keys without seeing those fcurves.
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
@digitallysane, My friend,
read this as respond to your last post to me and to relief your misunderstanding about the problem in a practical example.
i can not do continue repeating myself again and again and telling the same story with different orthography in post after posts.
so please read this more precisely.
if i brought in the animation editor look as a deduction tool, it was just for more clarifying of the subject. by involving the dopesheet editor in discussion you only make the matter more confusing.
i am seeing many animators in maya world (todays character animation lead package) that never touch the dopesheet editor at all, and make their all job down in other editors and UIes. (i don't want to say dopesheet is useless.)
involving dopesheet editor doesn't add anything to the discussion. the same rectangle shape loyal to integer frames that has issued that scaling problem now we see in another editor with exactly the same problem.
if you are doubtful yet about what is the problem, i shall describe one last time the problem. i hope this time you be able to get what is the issue in practical world.
so,
animators are thinking in 24fps and keyframes are at integer frames, ala what you are seeing in the dopesheet, yes your right. but caution, thats just the final look.
here we are talking about the process which leads the animator to that final look not only the final look itself solely. this is a common way of working that animator starts by setting keys at integer frames, and then at some points that will come surely, decides to scale them up or down for tuning his animation. this leads certainly to floating number keyframes. when he got satisfied of the final look, he retrieves keyframes exactly over integer frames for final rendering via a fcurve BAKING PROCESS.
but at that scaling phase, houdini timeline with current architecture makes annoying difficulties for the animator and kills some of his hardly crafted keyframes.
did you understand now, why we need floating point frame placement of keyframes? i hope you did. i can not explain this better.
regarding the abstract example, this is a common way for describing of weired situations in problem solving. these abstract examples make the foundation of what we see as a general final solution for every problem. these are main building blocks of the final solution. if we obscure them the solution might work in some degree, but failing at some points. just look to that super fast cartoony example in the first post. yes, animators certainly can make their animations currently in the houdini timeline, but that scaling abstract example is troublesome and reveals itself somewhere.
abstract examples addressing extreme conditions.
that was for, after scaling keyframes in the timeline not for setting fresh keyframes in the timeline. please read posts carefully.
i don't want to bother anyone. that in there was just a par reaction to your aggressive reply. please read and think and write in peace, then you'll get most of your answers. previous posts were enough informative.
I'm not agree with you. SESI people are hearing all voices always, and choose most appropriate solutions when they want to focus on a specific subject in their development road map.
i think i told everything was necessary.
read this as respond to your last post to me and to relief your misunderstanding about the problem in a practical example.
i can not do continue repeating myself again and again and telling the same story with different orthography in post after posts.
so please read this more precisely.
if i brought in the animation editor look as a deduction tool, it was just for more clarifying of the subject. by involving the dopesheet editor in discussion you only make the matter more confusing.
i am seeing many animators in maya world (todays character animation lead package) that never touch the dopesheet editor at all, and make their all job down in other editors and UIes. (i don't want to say dopesheet is useless.)
involving dopesheet editor doesn't add anything to the discussion. the same rectangle shape loyal to integer frames that has issued that scaling problem now we see in another editor with exactly the same problem.
if you are doubtful yet about what is the problem, i shall describe one last time the problem. i hope this time you be able to get what is the issue in practical world.
so,
animators are thinking in 24fps and keyframes are at integer frames, ala what you are seeing in the dopesheet, yes your right. but caution, thats just the final look.
here we are talking about the process which leads the animator to that final look not only the final look itself solely. this is a common way of working that animator starts by setting keys at integer frames, and then at some points that will come surely, decides to scale them up or down for tuning his animation. this leads certainly to floating number keyframes. when he got satisfied of the final look, he retrieves keyframes exactly over integer frames for final rendering via a fcurve BAKING PROCESS.
but at that scaling phase, houdini timeline with current architecture makes annoying difficulties for the animator and kills some of his hardly crafted keyframes.
did you understand now, why we need floating point frame placement of keyframes? i hope you did. i can not explain this better.
regarding the abstract example, this is a common way for describing of weired situations in problem solving. these abstract examples make the foundation of what we see as a general final solution for every problem. these are main building blocks of the final solution. if we obscure them the solution might work in some degree, but failing at some points. just look to that super fast cartoony example in the first post. yes, animators certainly can make their animations currently in the houdini timeline, but that scaling abstract example is troublesome and reveals itself somewhere.
abstract examples addressing extreme conditions.
digitallysane
Yes, here:
that was for, after scaling keyframes in the timeline not for setting fresh keyframes in the timeline. please read posts carefully.
digitallysane
The fact that you don't agree with something (or don't understand it) doesn't make it wrong. No matter how long or agressive your posts are.
i don't want to bother anyone. that in there was just a par reaction to your aggressive reply. please read and think and write in peace, then you'll get most of your answers. previous posts were enough informative.
digitallysane
Considering recent history, the fix will probably be a preference, which seems to be lately the way to deal with very vocal users.
I'm not agree with you. SESI people are hearing all voices always, and choose most appropriate solutions when they want to focus on a specific subject in their development road map.
i think i told everything was necessary.
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
FIRST OF ALL
pleas look at this subject from animators POV not VFX artists POV, then …
did i say we haven't possibility of setting keyframe on float frame numbers in the timeline ?!!!!
the post is all about keyframes rectangle shape drawing in the timeline not keyframes actual time, and also shrinking (scaling down) multiple keyframes in N to N+1 frame range issue.
the post is such dramatic so that people, do open their soporific eyes and look to the post more precisely and then do start writing reply.
now do this one.
1. create a box, for tx:
2. set a keyframe at frame 0
3. set a keyframe at frame 1
4. open the animation editor for tx
what are you seeing?
a big block which has occupied the range 0 to 1,
or 2 dots (your abstract point in time) with a connector spline (a segment of created fcurve). 3 components in 0 to 1 range.
how would be exact representation of those two keyframes in 0 to 1 range as rectangle shapes (NOT BEYOUND THE 0 TO 1 RANGES. those time ranges belong to another abstract points in time.) in a form that be readable at the same time by the animator. send me a picture.
if you are thinking yet, for drawing second keyframe rectangle from 1 to 2 range, set your second keyframe at float frame 0.5 instead of integer frame 1.
are you able distinguish two keyframes shapes in the timeline from each other? i see just one rectangle not two. do you see your two keyframes as two rectangles? is the rectangle, an exact representation of keyframe in the timeline in current format which is placing on just integer frames?
it might. but this bug is issued due to that wrong assumption. what will be the fix? drawing them all over each other in current format (HINT: keyframes shape positioning in timeline is just limited to integer frame numbers only now). again, the same issue described in setting two keyframes at frame 0 and frame 0.5.
now you see why i offered those new shapes with the ability for placing over float frame numbers along with a spearhead in the middle for pointing to actual frame number.
NOP, this is false. given a limited active range for the timeline. for example 1 to 9, and do the examples. you see …
i agree with you in this case and that is the reason why i wrote such a dramatic post, along that dramatic picture, and those dramatic new keyframe shapes
pleas look at this subject from animators POV not VFX artists POV, then …
digitallysane
Before writing such dramatic posts, do yourself a service and read the docs.
You can have floating point representation, even in the timeline.
did i say we haven't possibility of setting keyframe on float frame numbers in the timeline ?!!!!
the post is all about keyframes rectangle shape drawing in the timeline not keyframes actual time, and also shrinking (scaling down) multiple keyframes in N to N+1 frame range issue.
the post is such dramatic so that people, do open their soporific eyes and look to the post more precisely and then do start writing reply.
digitallysane
But when you don't (which is most of the time), having those rectangles is an exact representation of what's happening (completely the opposite of what you say).
A keyframe *does* have a length, like any other frame. It's not just an abstract point in time.
now do this one.
1. create a box, for tx:
2. set a keyframe at frame 0
3. set a keyframe at frame 1
4. open the animation editor for tx
what are you seeing?
a big block which has occupied the range 0 to 1,
or 2 dots (your abstract point in time) with a connector spline (a segment of created fcurve). 3 components in 0 to 1 range.
how would be exact representation of those two keyframes in 0 to 1 range as rectangle shapes (NOT BEYOUND THE 0 TO 1 RANGES. those time ranges belong to another abstract points in time.) in a form that be readable at the same time by the animator. send me a picture.
if you are thinking yet, for drawing second keyframe rectangle from 1 to 2 range, set your second keyframe at float frame 0.5 instead of integer frame 1.
are you able distinguish two keyframes shapes in the timeline from each other? i see just one rectangle not two. do you see your two keyframes as two rectangles? is the rectangle, an exact representation of keyframe in the timeline in current format which is placing on just integer frames?
digitallysane
The scaling inside one frame that you described is just a bug and should be reported as such.
it might. but this bug is issued due to that wrong assumption. what will be the fix? drawing them all over each other in current format (HINT: keyframes shape positioning in timeline is just limited to integer frame numbers only now). again, the same issue described in setting two keyframes at frame 0 and frame 0.5.
now you see why i offered those new shapes with the ability for placing over float frame numbers along with a spearhead in the middle for pointing to actual frame number.
digitallysane
If doing “compression” of many keyframes when in floating point time mode, thay should maybe just scale proportionally the width of the keyframes (because, indeed, they do represent “less” time).
NOP, this is false. given a limited active range for the timeline. for example 1 to 9, and do the examples. you see …
digitallysane
To use lines in representing keyframes is much less usable IMO (it's less readable and offers less information).
i agree with you in this case and that is the reason why i wrote such a dramatic post, along that dramatic picture, and those dramatic new keyframe shapes
Houdini Lounge » Houdini timeline wrong convention
- sorian
- 49 posts
- Offline
houdini is drawing its keyframes in the timeline as rectangles that their width size, has been expanded from frame N to frame N+1 and placing only on integer frame numbers.
this is completely a wrong convention.
why?
follow below example.
set 3 keyframes with different values at frame 1, 2, 3.
go to animation editor, and scale them down so that all of them to be placed between frame 0 and frame 1.
every thing is OK. we see three keyframes in the 0 to 1 range.
do the same steps but this time do the scaling, in the timeline.
BOOOMMMMMM…. one keyframe has eaten other two ones.
so, what happened?
everything in the animation editor is OK because it represents the keyframe as a point in time. TRUE way of keyframe representation.
but animation has been destroyed in the timeline because it represents keyframe as a time range (frame N to frame N+1) and holds them just on integer frame numbers and doesn't allow placing them in float frame numbers. WRONGE way of keyframe representation.
now imagine a character animator is working on a super cartoony shot that has keyframes every one or two frames and wants to make it faster.
he\she scales down the keyframes placing on some continues frame numbers and thinking logically that keyframes is still there yet, but now on floating frame numbers. some minutes later wants scale them a little up some frames, and then …….uh, where are my hardly tuned keyframes.
yes, houdini has betrayed the animator. it decides the animator doesn't need the keyframes and has deleted them. just because keyframes must be that type of rectangle shape and place over just integer frames.
this is the reason why a keyframe should be a point in time (simple line shaped keyframes in other apps' timeline) not a range in time (houdini rectangle shaped keyframes).
so that nothing bad would happen between rectangle fans vs line fans in regard to keyframe shapes, i recommend a third approach:
a rectangle with the width expanded from (N-1)/2 to (N+1)/2 that vertically doesn't cover the whole timeline height. it contains certainly a spearhead section that showing the animator, true frame number which it is pointing toward it. these keyframes will be able to place over floating frame numbers too in an overlaid mode.
here is two possible shapes of mine, in the attached picture.
PS. i talked about, in picture “tuner” term (animation editor version), in this link.
https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=42069 [sidefx.com]
this is completely a wrong convention.
why?
follow below example.
set 3 keyframes with different values at frame 1, 2, 3.
go to animation editor, and scale them down so that all of them to be placed between frame 0 and frame 1.
every thing is OK. we see three keyframes in the 0 to 1 range.
do the same steps but this time do the scaling, in the timeline.
BOOOMMMMMM…. one keyframe has eaten other two ones.
so, what happened?
everything in the animation editor is OK because it represents the keyframe as a point in time. TRUE way of keyframe representation.
but animation has been destroyed in the timeline because it represents keyframe as a time range (frame N to frame N+1) and holds them just on integer frame numbers and doesn't allow placing them in float frame numbers. WRONGE way of keyframe representation.
now imagine a character animator is working on a super cartoony shot that has keyframes every one or two frames and wants to make it faster.
he\she scales down the keyframes placing on some continues frame numbers and thinking logically that keyframes is still there yet, but now on floating frame numbers. some minutes later wants scale them a little up some frames, and then …….uh, where are my hardly tuned keyframes.
yes, houdini has betrayed the animator. it decides the animator doesn't need the keyframes and has deleted them. just because keyframes must be that type of rectangle shape and place over just integer frames.
this is the reason why a keyframe should be a point in time (simple line shaped keyframes in other apps' timeline) not a range in time (houdini rectangle shaped keyframes).
so that nothing bad would happen between rectangle fans vs line fans in regard to keyframe shapes, i recommend a third approach:
a rectangle with the width expanded from (N-1)/2 to (N+1)/2 that vertically doesn't cover the whole timeline height. it contains certainly a spearhead section that showing the animator, true frame number which it is pointing toward it. these keyframes will be able to place over floating frame numbers too in an overlaid mode.
here is two possible shapes of mine, in the attached picture.
PS. i talked about, in picture “tuner” term (animation editor version), in this link.
https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=42069 [sidefx.com]
SI Users » Compounding in Houdini?
- sorian
- 49 posts
- Offline
it will not be a one to one fair comparison if we do compare fabric against whole houduni system. at least fabric will need about 3 decades of houdini development time to get assets that houdini currently has as its features. just think about how much time and effort SESI put for its FEM solver that fabric needs to put to write via its KL. houdini as a whole system, specially regarding SESI new trend for making its animation and modeling toolsets parallel to its VFX capabilities, is able for smashing not just fabric, rather many other tools in the market too.
but fabric as a development platform has some goodnesses, which i mentioned in previous post that we like to would have them in the VEX\CVEX context. then houdini will be ultimate unbeatable beast in the industry.
we get used to see any of other tools in the market in its highest functionality and capability as a feature in houdini.
but fabric as a development platform has some goodnesses, which i mentioned in previous post that we like to would have them in the VEX\CVEX context. then houdini will be ultimate unbeatable beast in the industry.
we get used to see any of other tools in the market in its highest functionality and capability as a feature in houdini.
SI Users » Compounding in Houdini?
- sorian
- 49 posts
- Offline
and those brains behind ICE now have made FABRIC. some new thoughts added to ICE experiment. delivering processes to GPU, automatic and custom multi threading capabilities, a lot of good stuffs going on there. somehow a complete object oriented programing analogous to C++ inside 3d app. i think we should look forward to compare this new technology vs houdini paradigm henceforth.
-
- Quick Links