PDA

View Full Version : Fabric Engine for Lightwave



Cyberfish_Fred
05-26-2015, 04:47 AM
http://fabricengine.com/2015/05/fabric-at-fmx-2015/

Are there already some developers working on to implement the Fabric Engine into Lightwav? It's free!

Freddy

bobakabob
05-26-2015, 07:06 AM
Hopefully, it seems to have amazing potential for creating new tools.

hrgiger
05-26-2015, 09:46 AM
I sure hope so. It's disappointing to see Modo get support for substance designer, opensubdiv, fabric engine and no indication of seeing support for these things in lightwave.

ianr
05-26-2015, 11:04 AM
Surely We(LW) CANNOT afford NOT be there,

Isn't that what someone was saying about 'Pipelinning'

Along with a NO show on the Houdini engine ?:compbeati

jwiede
05-26-2015, 02:03 PM
If a plugin cannot be written today in C/C++ or Python due to LWSDK / LW infrastructure limitations, then it is very unlikely a third-party-integrated Fabric:Slice integration will allow doing so, because the limitations stem from the LW SDK infrastructure. OTOH, if LW3DG were doing the integration, then obviously they could grant it the kind of deep access needed to resolve (some of) those feature access limitations.

The real question seems to be: Would users be interested in a Fabric Engine integration, if that integration didn't grant additional access/capabilities beyond what could be achieved in a third-party C/C++ or Python plugin/node today? If it offered a visual programming alternative to writing nodes in C/C++, lscript or Python, but nothing more, would that be acceptable?

hrgiger
05-26-2015, 03:45 PM
If a plugin cannot be written today in C/C++ or Python due to LWSDK / LW infrastructure limitations, then it is very unlikely a third-party-integrated Fabric:Slice integration will allow doing so, because the limitations stem from the LW SDK infrastructure. OTOH, if LW3DG were doing the integration, then obviously they could grant it the kind of deep access needed to resolve (some of) those feature access limitations.

The real question seems to be: Would users be interested in a Fabric Engine integration, if that integration didn't grant additional access/capabilities beyond what could be achieved in a third-party C/C++ or Python plugin/node today? If it offered a visual programming alternative to writing nodes in C/C++, lscript or Python, but nothing more, would that be acceptable?

I don't think you're correct in this at all. Fabric is platform independent allowing for deformations, rigging and many other types of tools to be interchangeable with completely different applications. Behind the scenes, it takes data from the host application, Fabric processes everything in its own engine, and then passes that information back to the host app in a way that can be used. It has little to do with any limitations LW might have in its SDK.

Its just that someone would have to supply the hooks for Fabric to connect to LW, much in the same way they are doing for Modo 901. After all, Modo has some of the same limitations that LW has.

jwiede
05-26-2015, 06:39 PM
Behind the scenes, it takes data from the host application, Fabric processes everything in its own engine, and then passes that information back to the host app in a way that can be used. It has little to do with any limitations LW might have in its SDK.
That's precisely my point: Fabric Engine is ONLY capable of operating on / processing data it can obtain from its host application, done using that host application's plugin SDK APIs. It has no magical ability to peer inside the host application data structures to extract non-API-exposed information. Obviously Fabric Engine can also create new data within itself, but it can only move that new data to the host application by using the available host SDK APIs which support modifying/pushing data back into the host. In either case, if the host app SDK APIs restrict or disallow moving types of data in/out from the host, neither Fabric Engine nor the third-party integration can create new host SDK APIs in order to do so.


Its just that someone would have to supply the hooks for Fabric to connect to LW, much in the same way they are doing for Modo 901.
For both modo and LW, the plugin SDKs are the host application hooks supplied for third-party extensions/integrations. The only way the provided plugin SDK APIs could change w.r.t. the integration would be if The Foundry (for modo), or LW3DG (for LW) were themselves doing the integration (iow, not third-party) because then they can obviously access internal/private non-SDK-published APIs and data structures should they so choose. There doesn't appear much likelihood of a first-party integration occurring, however, and this thread was focusing on third-party integration. Third-parties are limited to the published SDK APIs and whatever unsafe-but-private APIs they happen to know about (recognizing that using private APIs obviously incurs serious incompatibility risks, ofc).


After all, Modo has some of the same limitations that LW has.
Can you give some examples of the types of SDK API limitations shared by modo and LW you mean, which are relevant to Fabric Engine (Fabric:Slice) integration? The (well-known) limitations of LW SDK APIs most relevant to such an integration (uneven access to APIs/data depending on which app is hosting, node stack isolation/absence, etc.) don't really have direct equivalents in modo's SDK APIs, because those limitations stem from LW's "separate app" implementation.

hrgiger
05-26-2015, 07:22 PM
Again, I think you're looking at this incorrectly. I don't have an intimate knowledge of Fabric's design and I'm assuming you don't either. But the way it was explained to me by someone who does is that Fabric is NOT hooking into an application like Modo by using its SDK to drive Modo functions. rather they are encapsulated Fabric specific tools which can then be moved to other applications. Modo plugins make use of Modo SDK fuctions, but Fabric is using only Fabric functions. So a deformation driven by Fabric is basically converted to a Modo deformation, its just being driven solely by Fabric Engine. Which is part of the beauty of Fabric. It doesn't matter how slow or fast Modo is, Fabric tools will work as fast as they do inside of Fabric because the Fabric Engine is what's driving it.

creacon
05-27-2015, 03:03 AM
I've looked at fabric splice (the glue between fabric and the host app), and LW has everything it needs in its SDK for the data exchange between the host and fabric. So there's no problem there. There will have to be a mixed bag of plugins (displacement for deformation, layout tool for the gizmo's, motion plugins, master plugin to keep things under control, ...).
It's not hard to do, but it's not fun either.

UI is a whole different thing, someone would have to write a customizable UI that displays properties (scalars, vectors, colors, integers, ....) and pass all this data to fabric and back. This needs to be done on-the-fly.
Panels are more or less complete, XPanels are horrible (incomplete) and a result of "I refuse to use C++ and classes so I am using macros for everything, so I can create unreadable code that is hard to debug" ;-)

The biggest question is why would anyone make the effort to do this? When a third party releases a plugin that costs $200, the biggest part of the people on this forum complain that it is too expensive. The users that benefit from Fabric (TD's mostly) are just a handful. So this would be a very expensive plugin that hardly anybody would use.

If Newtek would decide however to switch the main UI code over to QT, the problem becomes a lot easier and then it could be doable.

creacon.

hrgiger
05-27-2015, 07:28 AM
Considering that Lightwave ui is long overdo for an overhaul...would love to see them go to QT.

ianr
05-28-2015, 06:09 AM
Thanks, Creacon, jweide & Hr for some very interesting

insights into under part of the hood! Considering the

remarks here could you tell me in your detailed opinons

whether we can get a Houdini engine working for LW

within the Community. As I understand that's how other's

where dev'ed, the code is on Github & freely available.

Has anyone done & Eval on the logistics of such a thing?

I would greatly value your remarks on thi:lwicon:s

creacon
05-28-2015, 06:55 AM
As far as I am concerned, it's the same story. How many people would use that? Most of the users haven't touched the nodes in LW, and they are real easy to use in comparison to Houdini.

I am not saying that nobody would do it, but it'll have to be someone with more time on their hands than I have.

creacon


Thanks, Creacon, jweide & Hr for some very interesting

insights into under part of the hood! Considering the

remarks here could you tell me in your detailed opinons

whether we can get a Houdini engine working for LW

within the Community. As I understand that's how other's

where dev'ed, the code is on Github & freely available.

Has anyone done & Eval on the logistics of such a thing?

I would greatly value your remarks on thi:lwicon:s

hrgiger
05-28-2015, 08:43 AM
There may be some SDK issues as Jwiede pointed out but I think they would be limited to things like perhaps changing topology in Layout or doing other things that LW might not be structured for already but I think that as far as deformations go, doing some very advanced animation and rigging could be done with Fabric in LightWave as well as some sophisticated effects. But again, I am only basing this off what I've been told and what I've read about Fabric.

I think Creacon hits on the more important aspect which is how feasible it is for LightWave. How many people would really make use of it? LightWave is certainly not the best app out there from a TD's standpoint. Some deep changes in LightWave could make it more feasible perhaps but we really don't know what LW3DG plans to do and they're not really engaging users on the LightWave they intend to bring us in the future.

jwiede
05-28-2015, 01:13 PM
There may be some SDK issues as Jwiede pointed out but I think they would be limited to things like perhaps changing topology in Layout or doing other things that LW might not be structured for already but I think that as far as deformations go, doing some very advanced animation and rigging could be done with Fabric in LightWave as well as some sophisticated effects.

If there were strong demand for someone to produce and sell such plugins, they could be done right now using lscript, Python, or C/C++. A LW-using studio or artist desiring such things could easily contract a programmer to write such plugins today. Fabric Engine doesn't really "increase the envelope" of what can be done in that regard, it would just provide another language/environment in which such plugins could be written.

Will adding another language/environment to write LW plugins somehow entice production of a bunch of plugins that otherwise wouldn't be written? Fabric Engine integration in LW only makes economic sense if the answer to that question is "yes". Honestly, I just don't see much evidence that it does or is.

If such plugin demand existed, you would expect to see the forums loaded with requests for deformers, etc. (that could be written in C/C++ today, but are not), and that just isn't the case. Instead, the requests most LW customers seem to be repeatedly demanding are explicitly not features that can be implemented as existing LW plugin types.

Right now, it just seems like a lot of work to implement something for which there isn't much latent demand. In time, that may change.

Thomas Helzle
05-31-2015, 06:25 AM
Well, I wouldn't think too much about who would actually use it - that way nothing will ever happen.
LWers are so used to things not being possible that missing demand isn't an indicator IMO. ;-)
Everybody else left a long time ago for greener pastures.

If Lightwave becomes easier to integrate into pipelines with tools like FE, things like the awesome renderer, free render nodes, not being Autodesk and other areas it excels at will attract the target crowd eventually. In the end, you could ask the same question for Modo and C4D - not your typical Splice users either, but I guess they have a more approachable SDK and larger users numbers in the meantime.

The main point missing seems to be the central entry point allowing to manage it all in one place like in Mayas hypergraph. If it would be scattered all over Layout in the motion, deformation, surface, instance, camera, bone etc. panels, it would defeat a lot of the purpose of making things easier.
I don't know if and how on-the-fly mesh insertion is possible at all (?).

But IF those roadblocks could be overcome, I am very sure that people would start using it, especially with the very approachable business model of FE, where individuals get the license for free and studios get 10 unlimited licenses + 40 render nodes for evaluation.

IMO it would make a lot of sense for the LW3Dgroup to think pretty hard about building the foundation into Layout to integrate such tools with a central place to attach to.
It would fit in perfectly with the overall direction Rob has taken - pipeline integration and building LWs strengths.

It could actually ease a lot of pressure on the team, since a tool like FE can take care of many of LWs shortcomings for the more demanding users.

Interesting times ;-)

Cheers,

Tom

creacon
05-31-2015, 03:54 PM
The central point could be a master plugin that manages all in one place, the other plugins could query shared memory or receive messages from the master plugin. On the fly polygon adding in Layout is also possible.
A small team should really focus and make choices of what they need to do and what they leave up to third parties. The improvements to the renderer, the instancing, the bug fixing, all that points in the right direction.

Chronosculpt, Nevronmotion, Genoma, all these point in the opposite direction. So I honestly don't know what to expect.

creacon

jwiede
06-04-2015, 08:39 AM
A much more "useful" (and likely, efficient) Splice integration would be attainable from LW3DG, compared to what third-parties could do, because LW3DG can extend the SDK where and as needed. OTOH, waiting for LW3DG to indicate they're pursuing Fabric Engine integration could also mean waiting forever to no avail.

Having a master plugin doesn't entirely resolve the "nodal silo" issue, it can bridge data (as could a comring) but each silo's evaluation points (and contexts) are still unique, it can't trigger those -- that greatly limits what can be usefully shared between silos. There's still useful sharing possible, as TrueArt's Global Materials demonstrated, but it winds up being primarily useful between evaluations within the same silo, instead of between silos.

Crush
06-09-2015, 07:30 AM
@Thomas Helzle: Thanks for releasing your great plugins for Messiah Studio - I often use a lot of them still playing a lot with Messiah V6 as one of the last few existing users. I also use Lightwave and Modo (also a bit Houdini sims and smaller apps) and was the first in the Foundry forum reporting of this information directly during the FMX time. Houdini Engine comes for Modo, too, btw!

Now to the Fabric Engine (FE):

I have talked a bit at the FMX with the fabric developers and it seems most people canīt really imagine how geometry is "transferred" or the rigs are integrated in the 3D-tools and what the fabric engine is in detail. So I try to describe it a bit better for you.

At first all calculation is done in the FE and it utilizes for this as much as possible multi-threading (hsa libarary: http://de.slideshare.net/hsafoundation/what-fabric-engine-can-do-with-hsa) and GPU programs with its own KL and phyton realtime compiler running as fast as pure optimized multi-threaded C++. Thereīs an external development suite with its own 3D-Loader and geometry / animation viewer or if your 3D-Program supports it, you can show it integrated in your standard working/animation viewports. For this the Splice engine has to be implemented on the tool site. Then all screen updates are implemented in an own speed maximized OpenGL drawing subroutine that has to be called before screen swapping (http://cgvfxing.com/2014/08/22/fabric-engine-splice-rendering/). All those OpenGL calls are done externally in the Fabric Engine that can be included as a single DLL. I donīt know if there is any port for DirectX, but Maya has a DX viewport and perhaps this is also supported somehow. All node-windows can also be opened in their own small windows. Iīm rather sure all variables you use or define in FE can be somehow exported and quickly accessed also in the integrating 3D-program. This means everywhere you can run Splice the playback speed and visuals should be very similar with slight speed differences depending on what the OpenGL viewport has to do for additional work on your scenes from your 3D-tool.

You can create your own complete rig code by hand or with the existing nodes as networks. Some help can be simplified with the creation platform (http://fabricengine.com/fabric-engine/rigging-animation/) or a perhaps more complex rigging toolset thatīs in development, called Kraken (http://fabricengine.com/kraken/).

It is possible to transfer all geometry from your favourite 3D-Tool into FE and back if the needed subroutines are implemented on both sides (therefore you need some kind of collaboration between both developer teams - FE and external 3D-Tool). Itīs speed depends a lot of the 3D-architecture and proper integration. For playback or animation you can rely if you wish to 100% on FE with Splice.
The FE integration can be expanded very deep, also to (genetic) textures and material, shading and rendering and itīs also in some way possible to utilize 3D-Tool dependant objects like splines or hair within FE (depends on how good and deep the collaboration is).

license costs: For single users and small studios you can ask for the 50 commercial seats license pack for free. Only bigger studios have to pay site licenses.
Itīs expected to have more and more of cool rigging tools, extensions and features available for free if the TDs release it for free usage. Thereīs also a lot of interesting things in the pipeline by the FE-team itself and some open source projects are cooking something. I think a big part if not the full FE sourcecode is on a GIThub available (https://github.com/fabric-engine) and can be extended on your own if youīre able and willing to do so - built your own FE suite if you like and your 3D-Tools allows a good integration. Asking the FE devteam can help including your own special nodes into the standard release if they accept it.

FE is not only rigging, itīs also possible to integrate external libraries/dlls in FE and offer the usage through itīs nodal system. So you also could offer or expect also simulation (muscle, hair, fluids, crowds), geometry generation/remeshing/pointclouds (also OpenVDB!) and all that makes its use available. This means you can use FE as a jump-board for other third party integrations. Later there also will be the possibility to protect and license expansions for FE if you want your creations commercially sold. The creation engine also can offer some extensions like hair guide generation and combing.

So I expect the FE to get >THE< effects library that will be sooner or later be a must have for EVERY bigger 3D-package in the future if you donīt want to fall back and create all features on your own or especially for your 3D-tool only. Itīs easier and more appealing for developers do create something once and use or perhaps sell it on several platforms without additional work.

creacon
06-09-2015, 08:58 AM
The fact that these are separated and only get called when it is relevant/safe to do isn't preventing me from doing anything I want. What do you want to do? Update the position of the vertices while the renderer is accessing them? Do you want to update the position of an object at the same time as moving the vertices/deforming?

Can you give me an example of something you can't achieve with the current SDK?

creacon



Having a master plugin doesn't entirely resolve the "nodal silo" issue, it can bridge data (as could a comring) but each silo's evaluation points (and contexts) are still unique, it can't trigger those -- that greatly limits what can be usefully shared between silos. There's still useful sharing possible, as TrueArt's Global Materials demonstrated, but it winds up being primarily useful between evaluations within the same silo, instead of between silos.

creacon
06-09-2015, 09:05 AM
@crush.

Very useful information. And it confirms our reasoning to get Fabric into our pipeline. Start using it under Maya and keep all the hard work if and when we decide to start using it in another application.
One thing I am not convinced of, but I would have to try it myself to make sure, is that it isn't creating an unnecessary overhead (double data) and that KL would be as fast as optimized c++ code.
But let's hope the advantages outweigh the drawbacks.

creacon

Thomas Helzle
06-09-2015, 10:00 AM
@Thomas Helzle: Thanks for releasing your great plugins for Messiah Studio - I often use a lot of them still playing a lot with Messiah V6 as one of the last few existing users. I also use Lightwave and Modo (also a bit Houdini sims and smaller apps) and was the first in the Foundry forum reporting of this information directly during the FMX time. Houdini Engine comes for Modo, too, btw!

Cool they are still useful! :-)
I stopped updating with messiah:studio 4.5 and stopped using it even earlier.
Amazing that the team was able to drive such a powerful and clever tool against the wall. It needed quite some special talent to not be successful with a software like this at the time. ;-)
Well, bygones and all that - but I still feel a sadness towards it like if you meet an old lover who was once the most beautiful and clever person and now is a wrack from sheer stupidity and neglect...

But I learned a lot, wrote my first C software ever, wrote extensive docs that helped many people with the nodes, got in contact with Taron and many other interesting artists, even my first job at Passion Pictures in London came through messiah and the shaders... I ported many of them to Mental Ray and Arnold witch opened other doors...
So nothing is ever wasted :-)

As for FE:
I ported my very first shader to LW some weeks ago. It's still buggy and not as much needed in LW as back then in messiah, but I found the LW SDK just as confusing as I remembered it from many years ago when I first tried a port.
From that limited exposure I can't really comment much on how feasible and elegant an FE integration could be and how much support from the LW group this would need (and how possible giving that support actually is).
Like you, I could imagine it being a major door-opener for LW back into the loop, getting out of the deadlock it is in ATM.

A recent rendering:

http://www.screendream.de/Site/assets/site/3D/Sculpture/SpiralingCradle.jpg

LW can still be a serious asset for studios and freelancers.
With FE/Canvas integrated it could be so much more.

Cheers,

Tom

Crush
06-09-2015, 10:04 AM
@creacon

Yes, youīre right. I thought Iīve seen a char showing the benchmark, but it could be Iīve seen this sentence about KL: “Ease of python with performance of threaded C++” (http://home.seekscale.com/blog/multithreading-in-vfx-pipeline-a-peek-into-fabric-engine) or Iīve mistaken it with the Javascript benchmark: (http://fabricengine.com/2011/11/server-performance-benchmarks/).

@Thomas Helzle
Iīm also a code and donīt think of anything is wasted if I learned something from developing it. Nice to see you working on LW shaders. Iīm sure youīll feel with SI similar to Messiah - I think you also used it a while because you also did a SI port of your shaders. To Messiah: With V6 Fori offered me all I needed to get fun with rigging and rendering again. I still hope and believe this will not be the end, otherwise Modo and LW are in rigging and rendering also very good right now to do most or similar effects like Messiah. I also would be very sad to leave it and can feel with you, because I had the same experience with Truespace a long time ago.

Returning to the fabric engine again:
Iīve seen theyīre also working on a realtime renderer with very nice quality and effects, so youīll be able to create nice animation previews / pre-visualization soon: (http://fabricengine.com/fabric-engine/rendering/)
This thing offers so much features itīll change the industry: (http://fabricengine.com/examples/ & http://fabricengine.com/blog/page/5/)
Someone also was asking about how FE compares to Softimageīs ICE system. The answer was: "Think of FE like ICE on steroids offering many more features!"

Thomas Helzle
06-09-2015, 10:47 AM
@ Crush: Yeah, Softimage XSI was my main tool from 2004/5 to about 2012. Don't even get me started ;-) Still my favourite polygon modeller...
But messiah was closer to my heart.

On FE: I think one very interesting aspect is, that you can switch FE between GPU and CPU without code changes.

And - as with Swift from Apple - script languages start to take on olden C++ and Co. left and right, especially compiled ones.
Since each node in Canvas is code and the resulting graph is compiled, this is quite different from your usual node tree.
I actually see a trend there:

This is running in a browser with scripting:
http://sub.blue/fractal-lab

This is also script-node-based, similar to FE/Canvas, but also using the cloud:
http://flowbox.io/

Interesting times indeed :-)

Cheers,

Tom

OFF
07-08-2015, 03:29 AM
It is almost time to Release The Kraken!
http://fabricengine.com/almost-time-to-release-the-kraken/

mummyman
10-06-2015, 12:36 PM
Anyone know anymore about this program? Or Fabric Engine 2?

rcallicotte
10-06-2015, 02:04 PM
I know I asked the developers there if they would consider LW and the answer was that someone at Newtek or one of us is welcome to bring it into LW. I'm all for it. These are the same people who created ICE for Softimage and they're geniuses and helpful and I'm very excited about what this could mean to Lightwave. Seriously.

mummyman
10-07-2015, 10:49 AM
If it's a seperate program, why does Newtek need to contact them or vice versa? Internal coding?

rcallicotte
10-07-2015, 11:28 AM
I think it needs to put its hooks in somehow. The basic idea is that if I program something in Fabric Engine 2, then any program out there that has this plugin can use it without changing anything. It is based upon the idea of a universal plugin. However, even if that does not work, I like what I've seen it do (from their website).


If it's a seperate program, why does Newtek need to contact them or vice versa? Internal coding?

mummyman
10-07-2015, 11:45 AM
Indeed! Thanks!