That why we need to learn KLPooby wrote:Canvas as it currently stands seems to be a relatively thin disguise for KL
I'm starting doing Fabric 'tutorials'
-
- Posts: 175
- Joined: 17 Apr 2014, 10:39
- Skype: nguyenvuducthuy
Re: I'm starting doing Fabric 'tutorials'
-
- Moderator
- Posts: 754
- Joined: 25 Nov 2009, 01:41
- Contact:
Re: I'm starting doing Fabric 'tutorials'
There shouldn't be words like disguise thrown around. Canvas is built on KL and that's a huge advantage. So many people wanted to be able to code their own nodes in ICE but simply couldn't because you would need to write C++. With Canvas, you can create your own scripted nodes now to do things you couldn't before and you don't get hit with a performance penalty.
I do agree that ICE held many people's hands and didn't require them to learn thoroughly what Math was really happening and abstracted away (too much IMO) the complexity of what it was doing. Sure it makes artists have access to it, but it also is a crutch. I do think there is still plenty of room to improve the discoverability for the artist types in Canvas though and debug drawing is one important area that needs some love. I think we should all keep in mind that Canvas is still at version 1.0. ICE wasn't perfect in its first roll out either.
Additionally, as Pooby said, Canvas is more generic than ICE. It has to be. It is a tool that can run in stand alone, in Maya, in Softimage, soon in 3ds Max and Modo, and eventually in Houdini. You have to build the system so that it allows you to take graphs from one to the other with the least amount of difference of workflow and capabilities. Otherwise you'll hit road blocks when trying to use a setup in Maya where it was expecting inputs from weight maps that you just don't have available in Maya. It's still improving every day and they take feedback seriously. Voice your opinions and on the forums.
I do agree that ICE held many people's hands and didn't require them to learn thoroughly what Math was really happening and abstracted away (too much IMO) the complexity of what it was doing. Sure it makes artists have access to it, but it also is a crutch. I do think there is still plenty of room to improve the discoverability for the artist types in Canvas though and debug drawing is one important area that needs some love. I think we should all keep in mind that Canvas is still at version 1.0. ICE wasn't perfect in its first roll out either.
Additionally, as Pooby said, Canvas is more generic than ICE. It has to be. It is a tool that can run in stand alone, in Maya, in Softimage, soon in 3ds Max and Modo, and eventually in Houdini. You have to build the system so that it allows you to take graphs from one to the other with the least amount of difference of workflow and capabilities. Otherwise you'll hit road blocks when trying to use a setup in Maya where it was expecting inputs from weight maps that you just don't have available in Maya. It's still improving every day and they take feedback seriously. Voice your opinions and on the forums.
Re: I'm starting doing Fabric 'tutorials'
Of course ICE has great points, I think I'll be a "kid of Softimage" to the end of my life. But it has not so bright points too. Let's say exactly that automatic context - while it helps to do things faster, once when it comes to compounds for use by others, it easily turns into sequence of workarounds, just to protect the user to do not kill some array, occasionally feeding it with constant value. Both ICE and Houdini are great in lazy, optimized evaluation, but, sometimes, one really wants to have more control, instead splitting the ICE trees or Houdini's lock and reload.FXDude wrote:Sorry let me rephrase,
I would think it would be considered as 'a reference' (or what to beat, at least in many regards) by more SI users (if not a majority of ICE users) than you would think or seem to yourself believe personally.
And that if it's often found to be reference, that it would only be rather loosely or very partly related to how it may have been gotten used-to, as opposed to just how convenient or versatile it (Soft/ICE) may have been.
Anyway, for me there's only two choices, because, well, SI is not developed anymore:
a: easy way, to proceed with character related stuff, like deformation, hair and so, in Houdini environment, which really isn't that much focused on that (app itself, community, everything), so entire story won't go anywhere further of being the possible 'vimeo star' . Or,
b: hard way , to re build the character and everything in Maya, always looking at Fabric as an additional option - with a much better chance to see someone else, utilizing my work. So I'm choosing the hard way Or it's not hard way, at all - for example, just newly added set of Alembic nodes into FE, allowing to get Alembic directly and combine SRTs and deformations, and to output result disk, all loaders savers and logic in same network, belongs to science fiction in any other system, these days. How to get the "all normals" thing, well I believe I'll manage this, somehow. By the way, still I don't see so much of additional KL involved, perhaps even nothing - but, yes I see the need for understanding the concepts, successfully hidden from us in ICE. Here I really feel grateful to Houdini, it really helped to figure out how it's possible to have a completely different approach, still doing the same.
Re: I'm starting doing Fabric 'tutorials'
In many ways, greater "user friendlyness" AND greater "flexibility" in software,
can be like "quality" and "performance" sliders for rendering.
If you move one slider up, the other one goes down, and not because of an invert expression, it's very difficult to have, never "everything", but as much of "everything" as possible.
Whereas in either case, there are things which can be done (with some amounts of sweat and ingenuity) to manage to move both sliders UP, without involving plugging another mouse to force both sliders at the same time
In the case of rendering, if you *only* focus on quality, while letting go of a watchful eye even for a second on performance, your render times will exponentially shoot WAY up.
And similarly concerning "human friendlyness", I think it's in that regard that many of the "hi-end 3D" products to an extent may have been missing, and where SI clearly had an edge despite sometimes indeed perhaps hitting certain limitations or walls at certain points.
But such possible limitations were *consitently* and *greately* offset by how much resources (in time, or in not needing rather scarse specialized specialist help, or involving becoming "system mechanics" ourselves) to get to all sort of results, and were very-much considered as "acceptable compromize", as this "friendliness" combined with a still quite high level of flexibility, also allowed for very creative solutions around all sorts of challenges.
And I think that has to do with the fact that BOTH flexibility AND "user accommodations" were BOTH pushed *from the start* and BOTH equally kept at a *very high priority*, concerning either ICE or the bulk of Soft in general, making for characteristics which even the most technically minded users also greatly appreciated.
Essentially making the 2 sliders go UP, not as far as some others have got one of them individually, (Like Houdini has always been *technically* somewhat more "flexible") but together seemingly quite a bit more than any put together, making things not only fast, but above all *accessible*, which I think is, and should be the key word.
Enough to think that the combination of BOTH may have died along with what "Softimage" (was/is) all about, (as much as it died, even if it still lives probably because of this very subject) which seem-ed to be about pushing exactly that combination, which consequently arguably had, and in all appearances (for example) -will- probably still have ... the most of "everything" at the same time, until some new (or existing) system is (further) engineered with at least similar priorities, or basic architectural design philosophies.
can be like "quality" and "performance" sliders for rendering.
If you move one slider up, the other one goes down, and not because of an invert expression, it's very difficult to have, never "everything", but as much of "everything" as possible.
Whereas in either case, there are things which can be done (with some amounts of sweat and ingenuity) to manage to move both sliders UP, without involving plugging another mouse to force both sliders at the same time
In the case of rendering, if you *only* focus on quality, while letting go of a watchful eye even for a second on performance, your render times will exponentially shoot WAY up.
And similarly concerning "human friendlyness", I think it's in that regard that many of the "hi-end 3D" products to an extent may have been missing, and where SI clearly had an edge despite sometimes indeed perhaps hitting certain limitations or walls at certain points.
But such possible limitations were *consitently* and *greately* offset by how much resources (in time, or in not needing rather scarse specialized specialist help, or involving becoming "system mechanics" ourselves) to get to all sort of results, and were very-much considered as "acceptable compromize", as this "friendliness" combined with a still quite high level of flexibility, also allowed for very creative solutions around all sorts of challenges.
And I think that has to do with the fact that BOTH flexibility AND "user accommodations" were BOTH pushed *from the start* and BOTH equally kept at a *very high priority*, concerning either ICE or the bulk of Soft in general, making for characteristics which even the most technically minded users also greatly appreciated.
Essentially making the 2 sliders go UP, not as far as some others have got one of them individually, (Like Houdini has always been *technically* somewhat more "flexible") but together seemingly quite a bit more than any put together, making things not only fast, but above all *accessible*, which I think is, and should be the key word.
Enough to think that the combination of BOTH may have died along with what "Softimage" (was/is) all about, (as much as it died, even if it still lives probably because of this very subject) which seem-ed to be about pushing exactly that combination, which consequently arguably had, and in all appearances (for example) -will- probably still have ... the most of "everything" at the same time, until some new (or existing) system is (further) engineered with at least similar priorities, or basic architectural design philosophies.
Re: I'm starting doing Fabric 'tutorials'
Well, not for everything... For small ( not so important) example, when it comes to blending the animation constraints against key framed SRT, Maya seems to be far more animator friendly, as it does allow to blend *only* if all required inputs are defined (by key frame or else), nicely setting the weight according to what is firstly created, keyframe or constraint. While SI allows to have 'do nothing meaningful' option, let's say if constraint's weight is between zero and one, and there is no key frame on SRT. I remember very well how long I needed to understand what on the earth is happening, found the explanation (I was able to understand) on forums, not in docs, after few screwed up rendered sequences. And... in 2004 I just had no courage to complain on forums, it was a different regime in these times... On opposite side, SI option allows to drive the weight by expression or else, *and* to clear all key frames, while Maya option for same thing asks for some special construction, because 'pairblend' node is 'nicely' deleted together with key frames, as there are no opposites anymore. So, by learning SI in 2004 and Maya today, I'm in 'wrong time', twice 2004 'not so user friendly' SI (to say politely) compared to Max and my knowledge, 2016 Maya makes jokes with me. While for users of old Softimage 3d, I guess everything was 'normal and best balanced' in 2004 with XSI, because they were introduced earlier.FXDude wrote:In many ways, greater "user friendlyness" AND greater "flexibility" in software,
can be like "quality" and "performance" sliders for rendering.
If you move one slider up, the other one goes down, and not because of an invert expression, it's very difficult to have, never "everything", but as much of "everything" as possible.
Whereas in either case, there are things which can be done (with some amounts of sweat and ingenuity) to manage to move both sliders UP, without involving plugging another mouse to force both sliders at the same time
In the case of rendering, if you *only* focus on quality, while letting go of a watchful eye even for a second on performance, your render times will exponentially shoot WAY up.
And similarly concerning "human friendlyness", I think it's in that regard that many of the "hi-end 3D" products to an extent may have been missing, and where SI clearly had an edge despite sometimes indeed perhaps hitting certain limitations or walls at certain points.
Back to topic, for understanding these casts, change types and so on, perhaps is good idea to to try re-assemble basic ICE setups in Houdini, equivalents of get-set data, especially to take look at all Attribute nodes, as an intermediate course.
Re: I'm starting doing Fabric 'tutorials'
Concerning Maya, no doubt there can be exceptions which as far as I can tell can mostly be isolated at best, while apart the myriad of things that are just not in the same ballpark in terms of being exactly "user-friendly", and despite that it did improve on certain fronts, more often than not still implies having to script your way to what effect you're after, or to get yourself out a bind.
I don't know if yourself script everyday, but for me while I can manage to do fairly simple things through scripting, I wouldn't want hours of debugging code to be between me and the goals that I may be after at a given time.
For me personally, debugging code is not what I want to do everyday, without implying limiting myself in any way in terms of how elaborate my goals may be... something which can otherwise be considered almost contradictory in terms, but which indeed has already been proven to be more than just a possibility, and a big point of the software this forum has traditionally been mostly about.
I don't know if yourself script everyday, but for me while I can manage to do fairly simple things through scripting, I wouldn't want hours of debugging code to be between me and the goals that I may be after at a given time.
For me personally, debugging code is not what I want to do everyday, without implying limiting myself in any way in terms of how elaborate my goals may be... something which can otherwise be considered almost contradictory in terms, but which indeed has already been proven to be more than just a possibility, and a big point of the software this forum has traditionally been mostly about.
Re: I'm starting doing Fabric 'tutorials'
With inevitable "I hate to say that", by comparing the SI and Maya kinematics *today*, I really can recognize elements in SI, probably aimed only to please the habits of small but in wide context irrelevant group of people, that is, Softimage 3d users who did not switched to Maya around 2000. And nobody else. Things like hierarchical non-uniform scaling, almost unusable shearing, canned IK setup. Which probably helped to get into current 'state'.FXDude wrote:Concerning Maya, no doubt there can be exceptions which as far as I can tell can mostly be isolated at best, while apart the myriad of things that are just not in the same ballpark in terms of being exactly "user-friendly", and despite that it did improve on certain fronts, more often than not still implies having to script your way to what effect you're after, or to get yourself out a bind.
I don't know if yourself script everyday, but for me while I can manage to do fairly simple things through scripting, I wouldn't want hours of debugging code to be between me and the goals that I may be after at a given time.
For me personally, debugging code is not what I want to do everyday, without implying limiting myself in any way in terms of how elaborate my goals may be... something which can otherwise be considered almost contradictory in terms, but which indeed has already been proven to be more than just a possibility, and a big point of the software this forum has traditionally been mostly about.
Back to FE, I'd say again that difference to ICE is more about concepts, not to this or that particular node. Certain node will appear, sooner or after. While these concepts are user friendly to... well... programmers, as people who should be in charge when it comes to visual programming system, also a human resource easy to find in huge communities of Maya and Max.
Re: I'm starting doing Fabric 'tutorials'
Is it possible to abstract Fabric with compounds to have something logic but not too heavy? Also is it more efficient than ICE, it is known that ICE compounds can have a performance penalty sometimes.
Btw in its current state Fabric can work with sound?
Btw in its current state Fabric can work with sound?
Re: I'm starting doing Fabric 'tutorials'
I think you mean system that exposes variables related only to final goal of system, in a way understandable by artist. If so, yes of course, their Psyop cases are showing something like that. I'd believe we will see more in upcoming FE for Modo.Bullit wrote:Is it possible to abstract Fabric with compounds to have something logic but not too heavy? Also is it more efficient than ICE, it is known that ICE compounds can have a performance penalty sometimes.
Btw in its current state Fabric can work with sound?
What I personally noticed, it's ability to process multiple geometries before they were used for some other purpose - this should save user of manually creating the copies of geometry - 'deform by uv' in other thread here on forum shows exactly that, it's one FE network against two ICE trees on two geometries.
Saw nodes for manipulation, too (painting, sculpting).
Can't say exactly about performance, right now I'm focused on deformation system, simply I'm not yet in stage of complexity where I'd be able to expect slowdowns.
If I'm correct, there is no sound processing.
Re: I'm starting doing Fabric 'tutorials'
Not having two icetree is good. Thanks for the overall feedback.
Re: I'm starting doing Fabric 'tutorials'
Part 2 & 3 of
Making Fur Dynamics from scratch
https://vimeo.com/155521155 Pt 2
https://vimeo.com/155668249 Pt 3
Making Fur Dynamics from scratch
https://vimeo.com/155521155 Pt 2
https://vimeo.com/155668249 Pt 3
Who is online
Users browsing this forum: No registered users and 42 guests