I'm starting doing Fabric 'tutorials'

New plugins, tools etc.
anhungxadieu
Posts: 175
Joined: 17 Apr 2014, 10:39
Skype: nguyenvuducthuy

Re: I'm starting doing Fabric 'tutorials'

Post by anhungxadieu » 17 Feb 2016, 09:57

hi there,

Anyone have a same problem with debug things in Fabric. For me it less flexible than softimage ice
i can't show a debug vector(direction, length ...), maybe i don't know or ...

User avatar
Mathaeus
Posts: 1778
Joined: 08 Jun 2009, 21:11
Location: Zagreb, Croatia
Contact:

Re: I'm starting doing Fabric 'tutorials'

Post by Mathaeus » 17 Feb 2016, 11:28

anhungxadieu wrote:hi there,

Anyone have a same problem with debug things in Fabric. For me it less flexible than softimage ice
i can't show a debug vector(direction, length ...), maybe i don't know or ...
You can do a search for ''inline drawing''. There are some examples too, coming in installation. However, it's more generic, also it's asking for few more little steps to get it to display, compared to ICE.

anhungxadieu
Posts: 175
Joined: 17 Apr 2014, 10:39
Skype: nguyenvuducthuy

Re: I'm starting doing Fabric 'tutorials'

Post by anhungxadieu » 17 Feb 2016, 11:55

i saw it's have inline drawing and debug drawing which is different category( i still don't know what different between them ). and always i want to see debug data i need to connect out port of that node to an out port of canvas operator(the root graph i should say :) ), that is very pain when you have a lot of sub graph.

User avatar
FXDude
Posts: 1129
Joined: 19 Jun 2012, 21:59

Re: I'm starting doing Fabric 'tutorials'

Post by FXDude » 17 Feb 2016, 20:57

While no doubt many things would get better with time, **for the moment** this kind of thing:
... it's asking for few more little steps to get it to [insert procedure here], compared to ICE
currently seems to apply to a relatively wide variety of things relative to ICE, including a number of 'missing' functions (without resorting to KL code)


It can be argued that some of these functions can involve but a few lines in KL, and that basic KL knowledge can go a long way.

Yet I wonder what can possibly prevent the inclusion of such basic functions, even if their own inner workings would be code as opposed to node based.

Considering that even "a few lines of code" which can take 2 seconds for a seasoned programmer/scripter, can for a layman involve spending much time minding quite sensitive & specific syntax or needing to come to an at least 'fair' level of knowledge to have it actually working, and that many users attracted to the visual aspect of visual programming mainly have that interest specifically to circumvent such technical requirements.

Also considering that even if many can be BOTH very technically AND artistically minded, and that most "digital artists" are at least a bit of both, for the very large majority of users in general, to a large extent is still more of an "either/or" kind of thing, mostly relating to *time* and what is prioritized to be done with it, and can be seen as the very premise/purpose of having things node based and visual.

Otherwise for data visualization, since a number of Fabric developers allegedly have an ICE background, one would think that it would have been one of the foremost priorities, and I'm sure many would be pleased if such capability were in the works.

User avatar
Mathaeus
Posts: 1778
Joined: 08 Jun 2009, 21:11
Location: Zagreb, Croatia
Contact:

Re: I'm starting doing Fabric 'tutorials'

Post by Mathaeus » 17 Feb 2016, 23:41

FXDude wrote:While no doubt many things would get better with time, **for the moment** this kind of thing:
... it's asking for few more little steps to get it to [insert procedure here], compared to ICE
currently seems to apply to a relatively wide variety of things relative to ICE, including a number of 'missing' functions (without resorting to KL code)


It can be argued that some of these functions can involve but a few lines in KL, and that basic KL knowledge can go a long way.

Yet I wonder what can possibly prevent the inclusion of such basic functions, even if their own inner workings would be code as opposed to node based.
Well exactly for 'visualizers', "[insert procedure here]" :) means connecting the 'visualizer node" to output port, as anhungxadieu already described. Getting the ICE style of visualizing, I think this obviously won't be just a few lines of KL code. Most likely ICE has an special, deep under the hood mechanism for that. If I can go into, what I think it is more relevant comparison these days - Houdini added the visualizers in V14, but developers were precious (that's my impression) in avoiding "core changes", there, so ergonomic is not comparable to ICE. It is somehow typical sequence of actions ( much longer than ICE), together with (also typical) dispersed info and controls.

However, in case of complete, well rounded system, dedicated for exact task, like built in ICE particles or custom tools based on ICE like Scatter Tools, Strand Tree and so on. I think it's possible to pack the FE visualizer somewhere inside compound, all that without any line of KL. While end user is still able to combine a very various sorts of inputs, geometries or plain logic, without any code. But, yeah, we still have to wait for such system.
For small, isolated example, very personally I'm slowly working on FE variance of this thing - where I believe I already see the all components without any KL - but I'm still not sure is there a way to expose the all controls in enough user friendly way for users of another apps ( which is a question of my design and ambition, not FE ). That is, a lot of SI end users were ready to learn some ICE basics, because this was only option for many tasks, while I don't believe this will work, once there is choice of dozens, much more user friendly plugins for Maya or Max. Or, in other word, I'm not sure if even ICE alone will be successful into 'open market' of widely accepted 3d apps. Perhaps we can remember the all complaints how ICE is *not* user friendly, so, I'm afraid ICE is able to work as 'reference of best', only for *some* of us, SI users.
Anyway, I have impression, that once we will see the 'complete and well rounded systems' based on FE, only 'victims' will be 'people in grey area', who want to be a sort of developers but do not want to write a code. Which really is special demand, I think. Shouldn't apply to end user who want to combine the forces and emitters, or anything focused to final result.

User avatar
FXDude
Posts: 1129
Joined: 19 Jun 2012, 21:59

Re: I'm starting doing Fabric 'tutorials'

Post by FXDude » 18 Feb 2016, 01:20

Hi,
I wasn't implying that an easily accessible visualizer would be but a few lines, just that some of the apparently missing nodes aren't at-all necessarily complex ones.

http://forums.fabricengine.com/discussi ... nt-normals
I'm not sure if even ICE alone will be successful into 'open market' of widely accepted 3d apps.
Exclusively in that regard, if mesured by that criteria (if at-all considered important) indeed it's probably the worst, and 3ds max would be the best.
Perhaps we can remember the all complaints how ICE is *not* user friendly,
Which I think should be a big part of the point in regards of the different solutions out there, while it's to this day one of the more approachable systems, there remained lots of room to make it yet more approachable still.
Leaping over the different contexts, or going a step further than it's already pre-adapting ports to what type of data is being fed in comes to mind...
so, I'm afraid ICE is able to work as 'reference of best', only for *some* of us, SI users.
I would think more so than you would think ;)

User avatar
Mathaeus
Posts: 1778
Joined: 08 Jun 2009, 21:11
Location: Zagreb, Croatia
Contact:

Re: I'm starting doing Fabric 'tutorials'

Post by Mathaeus » 18 Feb 2016, 02:07

FXDude wrote:Hi,

so, I'm afraid ICE is able to work as 'reference of best', only for *some* of us, SI users.
I would think more so than you would think ;)
Now you're cryptic - so what's difference of 'only few lines of code' against 'I would think more so than you would think'. From what we have chance to read, big players like Japanese game facilities weren't impressed. Many freelancers weren't impressed, too. Maybe someone in middle was, who wasn't able to afford the real developing, still having some resources.
All that in 'no another choice' environment. Rest is something emotional, I'd say.

User avatar
FXDude
Posts: 1129
Joined: 19 Jun 2012, 21:59

Re: I'm starting doing Fabric 'tutorials'

Post by FXDude » 18 Feb 2016, 03:00

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.

anhungxadieu
Posts: 175
Joined: 17 Apr 2014, 10:39
Skype: nguyenvuducthuy

Re: I'm starting doing Fabric 'tutorials'

Post by anhungxadieu » 18 Feb 2016, 03:49

Mathaeus wrote:From what we have chance to read, big players like Japanese game facilities weren't impressed
Right now i still don't know why many Japanese used Softimage instead of Maya, maybe they like me :ymblushing: . For me what make ICE and Softimage interesting with me is it's very artist friendly ... What make develop thing difficult for artists is how to access to a data and how to know it exist. In softimage we can easily to do it because objects in softimage work like a container and it contain everything, it's easy to get and easy to see.

Pooby
Posts: 501
Joined: 27 Aug 2010, 22:25

Re: I'm starting doing Fabric 'tutorials'

Post by Pooby » 18 Feb 2016, 10:08

The thing I noticed first from Fabric is how it's generic and isn't designed to read any softimage specific data. only generic data.

It's like the difference between an Obj as opposed to a softimage object. You realise how much isn't there and now it's just the fundamentals.

It made me realise how much ICE is holding my hand and going everything in its power to help me and make life easy.

Fabric Canvas is ultimately far more powerful than ICE, but yes I can't pretend it's as easy.

Canvas as it currently stands seems to be a relatively thin disguise for KL. It hasn't got ICE's level of abstraction to the user, neither it's interaction.

It's harder to experiment, as to a much larger degree, you have to know what you are doing beforehand whereas with ICE you can noodle around live, and see what happens.

People complain about ICE Context. What they might not be aware of is what Context is actually shielding you from. If you knew that, you might be wanting to kiss Context on the face.

I don't want to sound like I'm poo pooing Canvas because I think we desperately need something like this, and it's always going to be less friendly when it's generic. It's not a design flaw - They have done a great job.
I want to dedicate a lot of time to learning it. However it could turn out to be a harder sell to the masses than I anticipated.

anhungxadieu
Posts: 175
Joined: 17 Apr 2014, 10:39
Skype: nguyenvuducthuy

Re: I'm starting doing Fabric 'tutorials'

Post by anhungxadieu » 18 Feb 2016, 10:30

Pooby wrote:Canvas as it currently stands seems to be a relatively thin disguise for KL
That why we need to learn KL :))

EricTRocks
Moderator
Posts: 754
Joined: 25 Nov 2009, 01:41
Contact:

Re: I'm starting doing Fabric 'tutorials'

Post by EricTRocks » 18 Feb 2016, 16:57

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.
Eric Thivierge
Lead Kraken Developer, Fabric Engine
http://fabric-engine.github.io/Kraken

User avatar
Mathaeus
Posts: 1778
Joined: 08 Jun 2009, 21:11
Location: Zagreb, Croatia
Contact:

Re: I'm starting doing Fabric 'tutorials'

Post by Mathaeus » 19 Feb 2016, 01:33

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.
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.
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.

User avatar
FXDude
Posts: 1129
Joined: 19 Jun 2012, 21:59

Re: I'm starting doing Fabric 'tutorials'

Post by FXDude » 19 Feb 2016, 20:57

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 :p


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.

User avatar
Mathaeus
Posts: 1778
Joined: 08 Jun 2009, 21:11
Location: Zagreb, Croatia
Contact:

Re: I'm starting doing Fabric 'tutorials'

Post by Mathaeus » 20 Feb 2016, 01:59

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 :p


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.
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.

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.

User avatar
FXDude
Posts: 1129
Joined: 19 Jun 2012, 21:59

Re: I'm starting doing Fabric 'tutorials'

Post by FXDude » 20 Feb 2016, 04:52

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 47 guests