Jump to content

Will there be a managed SDK for Houdini in the future?


magneto

Recommended Posts

More and more 3d apps seem to add support for this, i.e. Max (tied to Windows, fair enough), XSI (multi-platform except mac).

I was just curious if SESI had any plans for offering some sort of managed SDK for C# and probably other .NET languages like F#.

I know Houdini is multi-platform and C# is generally associated with Windows, but it's not tied to Windows, unlike Microsoft .NET. And then there is mono.

From my experience for a lot of heavy duty tools, C# is a very popular choice for compiled tools.

Link to comment
Share on other sites

I think it depends on how you attack a problem.

The HDK is most likely best for custom shaders and nodes that deal with specific challenges inside Houdini, and since cooking times impact the performance and usability of Houdini. I wouldn't recommend something like C# for developing a SOP that had to process a large data set of attributes or geometry. C# also has a completely different memory management approach then C++, which makes mixing the two very difficult. You would most likely, end up writing C# code marked as "unsafe" to the compiler, with memory pointers and structures. To the point, that it would make it useless to have developed the code in C# to being with.

Where C# would be effective, is developing tools for a production pipeline. Like render management, layer management, object naming/rename, etc.. etc.. stuff like that would ideal.

I'd recommend using some kind of bridge between .NET and Python rather then touch the HDK. That way you could call your C# tools by importing their packages into assets using Python.

Maybe one of these will help?

http://pythonnet.sourceforge.net/

http://ironpython.net/

http://python.net/crew/theller/ctypes/

The other problem, is that the majority of developers for Houdini are HDK/Python users. So it's going to be hard to get help if you run into trouble, cause they'll have no reference point or interest in C#.

Link to comment
Share on other sites

I think it depends on how you attack a problem.

The HDK is most likely best for custom shaders and nodes that deal with specific challenges inside Houdini, and since cooking times impact the performance and usability of Houdini. I wouldn't recommend something like C# for developing a SOP that had to process a large data set of attributes or geometry. C# also has a completely different memory management approach then C++, which makes mixing the two very difficult. You would most likely, end up writing C# code marked as "unsafe" to the compiler, with memory pointers and structures. To the point, that it would make it useless to have developed the code in C# to being with.

Where C# would be effective, is developing tools for a production pipeline. Like render management, layer management, object naming/rename, etc.. etc.. stuff like that would ideal.

I'd recommend using some kind of bridge between .NET and Python rather then touch the HDK. That way you could call your C# tools by importing their packages into assets using Python.

Maybe one of these will help?

http://pythonnet.sourceforge.net/

http://ironpython.net/

http://python.net/crew/theller/ctypes/

The other problem, is that the majority of developers for Houdini are HDK/Python users. So it's going to be hard to get help if you run into trouble, cause they'll have no reference point or interest in C#.

Thanks man, I see what you mean. Although I don't think C# would be slow for large sets of data. I can't speak for Houdini but I have done many experiments using Max's .NET SDK, and it's very close in speed to its C++ counterparts. For instance I wrote a modifier that deforms a very high res mesh in Max, and it worked flawlessly. The guy who wrote this wrapper SDK is also doing some pretty cpu intensive stuff.

Also the productivity gain I got from using C# to write a Max plugin was unbelievable. I am talking about figuring out what boiler plate code and "redundant" code to use, to jumping right into implementing your custom logic. I actually sent a few samples to an Autodesk developer and he was baffled, because of simplicity of the code and speed, all using the same old Max SDK underneath.

You could also use F# to write your Max plugins.

Check out this article:

http://abdullin.com/journal/2009/1/6/f-has-better-performance-than-c-in-math.html

Just my opinion.

Edited by magneto
Link to comment
Share on other sites

ah to write plugins for Max quickly. How things have changed since I last worked with the SDK. Just getting an empty modifier setup and to compile would take about a day.

I would just be reluctant to be hosting C# plugins when memory resources are sometimes critical during rendering, especially on a farm where every bit matters. While most Houdini users do use Windows, often the render farm is running Linux. Where as, on the 3ds Max platform it can be assumed the farm is Windows based. Still, it does have to load C# to bake the geometry needed to render cause in 3ds Max it has to process all the modifiers at render time. That does seem a little heavy to me? I guess it depends a lot on what the tool does compared to the time it took to develop.

I've worked at a place were we were doing both Java and C++ development, and I was hoping the days of developers debating the pros/cons of two languages were long behind me ;)

Link to comment
Share on other sites

ah to write plugins for Max quickly. How things have changed since I last worked with the SDK. Just getting an empty modifier setup and to compile would take about a day.

I would just be reluctant to be hosting C# plugins when memory resources are sometimes critical during rendering, especially on a farm where every bit matters. While most Houdini users do use Windows, often the render farm is running Linux. Where as, on the 3ds Max platform it can be assumed the farm is Windows based. Still, it does have to load C# to bake the geometry needed to render cause in 3ds Max it has to process all the modifiers at render time. That does seem a little heavy to me? I guess it depends a lot on what the tool does compared to the time it took to develop.

I've worked at a place were we were doing both Java and C++ development, and I was hoping the days of developers debating the pros/cons of two languages were long behind me ;)

Oh man, Max did come a long way in terms of plugin development. You know it's still the number one app with the most and best plugins. Props to the original devs who grinded through all those obstacles.

I think nowadays you can use maxscript, maxscript with .NET, pure .NET using maxscript execute calls (pre-.NET SDK), python (unofficial from Blur), C#, F#, IronPython and any other .NET language using the .NET SDK, and last but not least the good ol' Max SDK.

That's alot of options. That's why I love Houdini's approach too. Many ways to do things and a lot of things are managed in many ways, i.e. not having to deal with undo/redo when you make an operator.

Edited by magneto
  • Downvote 1
Link to comment
Share on other sites

Here we go. I should keep my mouth shut, but I can't :)

Don't you think the biggest problem with 3ds Max, is it's plug-in nature? All those different ways, different languages, different coding standards, and open backdoors makes for a horrible user experience in the end?

Max has one of the most inconsistent user interfaces. There are so many third-party plugins that Autodesk has purchased, and included in the box, which have completely different implemented user features. This particle tool works with that particle tool, but no that other particle tool. This modifier has hot keys for this feature, but the exact same feature in another modifier has different hot keys for the same thing. One tool has a popup window that uses nodes that work in a way unlike an other feature, and then another node network is drawn/works completely different here and then there it's different again.

Then Autodesk comes along and implements this ribbon interface, because let's face it. Everyone on a 24" 1080p knows they've got lots of screen real-estate to spare.

The thing that makes Houdini so amazing, is how you can develop assets with little or no coding and how consistent the user experience is for people who use those assets. All the assets feel consistent, and there is little or no learning curve to use new ones. Plus, you never hear Houdini users say "Don't download free OTLs from the Internet, because they'll make Houdini unstable and crash a lot". That doesn't mean they all work, but if you download a few hundred plugins for Max. You're committing stability suicide. That's why Autodesk changed Max so you had to enable/disable plugins when you need them.

Anyway, sorry for the rant. I think I have some unsettled Max issues that still needs working out in therapy. It had such potential and Autodesk just screwed it all up. Apple is a great example of why it's good for a company to put restrictions on what developers can do. It ensures a good user experience for their customers, and forces the developers to conform or leave.

Edited by hopbin9
  • Like 1
Link to comment
Share on other sites

@magneto

Check this at I programmer - it is possible MS will drop .net.

Thats July old news.

At Build conference they introduced what will be in Win 8.

Win8Platform.png

.Net problem was that you couldn't use C++ to write applications for WPF/Silverlight. XAML with C++ was not supported. In Win8 this will change and all three language families will have equal acces to graphic libraries and C/C++ will got XAML too. Thats for Metro apps. For desktop apps it will stay like it was till now.

It doesn't matter if .Net will be supported or not, core language libraries will not change. They will not rewrite language just because they dump .Net. Acces to some UI and kernel functions is changing so is additional libraries but language itself will stay where it is now.

Unity doesn't have problems with using C# and it works on most desktop/mobile platforms out there. They just use mono. Don't know if it is full mono or just modified to their needs subset, but it works exactly the same everywhere. You can implement you own C# with all standard libraries that makes language indepedently from .Net.

Link to comment
Share on other sites

More and more 3d apps seem to add support for this, i.e. Max (tied to Windows, fair enough), XSI (multi-platform except mac).

I was just curious if SESI had any plans for offering some sort of managed SDK for C# and probably other .NET languages like F#.

I know Houdini is multi-platform and C# is generally associated with Windows, but it's not tied to Windows, unlike Microsoft .NET. And then there is mono.

From my experience for a lot of heavy duty tools, C# is a very popular choice for compiled tools.

Natural place for .NET platform is HOM, which is an API serving Houdini's internals to aliens (like currently Python interpreter), so C# would behave in Houdini pretty much like Python, with all pros&cons (like read-only access to frozen gdp outside a node, limited number of callbacks, single threaded UI etc). Houdini doesn't have any other API .NET/Mono could be wrapped around, so afaik introducing it to Houdini is more a problem of API, than platform itself. Wrapping a whole HDK seems to be unrealistic if not impossible at first place.

The platform itself however is anther subjects of considerations. Is it really multi-platform, how about its maintenance, does it have any future? I doubt anyone would bet on it, if it was a pure Mono project (which is supported by MS anyway), without MS supporting the majority of people at .NET. In other words,my opinion is that Mono is an artificial project and it wouldn't exists if MS wouldn't like to prove .NET is multi-platform. Knowing things a bit, I presume SESI would have to pack up own mono compilation and ship with Houdini. Dependency with the fig leaf in essence.

Additionally, anyone who tried to pair .NET application with right Mono version on Linux, knows how great idea is to bring into your pipeline "OS independent" library designed by MS.

Surely there would be some pros, as C# plugins wouldn't be so dependent of builds versions, free and good windowing, threading etc, but this is valid under assumption HOM or any other API would allow C# to coexist inside Houdini, which as I suppose is not a trivial task. (and in fact it looks like the main advantage of .NET in Max was how it changed Max to make it happen).

Finally Adsk seems to manage business differently for a purpose - suited to its multi-market clients (with games in focus). But having many languages to your disposal doesn't make your life any good by itself. In fact these 5 or 6 different languages in XSI talk to the same API deriving the same bugs from it, adding its own to the bin, along with number of inconsistencies in API's calls and documentation. I definitely don't see SESI going this way, specially that Houdini already have its babel tower, but at least these 5 languages supported in Houdini serve different purposes (and some are legacy thing) - and afaik C# without changing Houdini itself would inherit the same limitations as Python.

I think SESI stays focused on tools already provided to make them better. Things like Python everywhere by extending HOM is happening, more Python Objects types, more serial routines handling well heavy data. Real pita compared to .NET is Houdini interface, single-threaded and in fact hardly scriptable. My secret dream is to have at least a QT-pane, which serves as a canvas for Qt widgets, if not just Qt everywhere - which I believe won't happen ever from philosophical reasons.

In terms of performance perhaps making Python and VEX more productive is better option, isn't it? Note that you can already call VEX from Python, read/write serialized attributes, but thing totally absent is a primitive context for VEX. Primitive VOP allowing to change topology, deal with bones and VEX extended to support structures, so you have very productive geometry engine suitable for things Python is a wrong bet.

  • Thanks 1
Link to comment
Share on other sites

@Swann

You are right this are old news - there have been changes (and there will be). You really cant predict the "next steps" by Redmond ;-)

And you are right - core language libraries will not change. But in my view: c# development depends a lot on .net.

In the current situation I wont bet on c#/.net and build a big project based on .net.

If they "freeze/kill/replace" .net and offer only core libraries, developer have to implement new core technologies in there own code. A lot of the .net-programmers are afraid because of this scenario.

Unity doesn't have problems with using C# and it works on most desktop/mobile platforms out there.

This is right - "on most". Do it worth to build and maintain a (mono based) system (multi plattform), to give "some" c# developers work in Houdini?

What will you do, if they dump Mono or there is not active development? There are to much ??? <_<

Link to comment
Share on other sites

Mmmm .NET, no please.

Just multiplatform languages.

Personally I can find any adventage of using any .NET tools comapred with the C++/Python tandem.

what else do you need.

.NET is not for this industry I think.

And just guessing, I think SESI will never support .NET languages.

Just a side point, Max is the first tool in plugins but not because of the quality of it's SDK. It is far from being good designed/documented.

The best thing in the Max SDK is that it is really open, basically becasue they when it was done some years ago develoers dont pay too much attention to correct design and just give you access to everything, which is good, but can also be very bad. This is one of the reasons Max used(?) to crash so much, bad plugin development.

Link to comment
Share on other sites

@Hopbin:

I don't think the plugin architecture is the problem. The many ways to extend Max doesn't really overlap much with each other. Each have different strengths and weaknesses and I know what to use for each scenario as each method serves a different purpose IMO.

I agree on the UI. A more unified, consistent UI like Houdini is far superior. Same with the workflow and uniformity with its features. Max fails in this and lacks the symmetry of functionality Houdini offers. Ribbon is another huge issue like you said. Autodesk buying 3rd party stuff with no one to maintain or understand the codebase is a huge flaw I saw coming when it first started happening.

I see extending 3d apps like Houdini as different levels myself. Each following level goes lower, might be harder but with different benefits. Sometimes it's good to make a deformer using a graph editor. Other times you just want to write a few lines of code instead of hooking up 100 nodes in a graph. In my view each has a place and a purpose. Sometimes it's preferential, sometimes a necessity. IMO here choice is a win.

@LEO-oo:

Same claims have been done for pretty much anything. Some people just love to start sh*tstorms ;)

@SWANN:

I think it's the same but Mono guys added stuff like SIMD for them where .NET doesn't provide one.

@Symek:

I don't think using HOM to hook .NET would be beneficial. It has to be at the SDK level. As for it's feasibility, Autodesk said the same thing that it's not possible. One guy single-handedly wrapped the whole SDK in a very short time. You can automate pretty much all of it using tools like SWIG:

http://www.swig.org/

Actually Mono was initially supported by Novell. Microsoft doesn't really care about Mono to be honest.

Also most trivial apps would compile fine on Mono but when you have a multi-platform requirement, it's better to develop on Mono originally.

Autodesk did nothing to Max codebase to have a .NET SDK. Their efforts of revamping the UI through .NET has totally different expectations. Max .NET is developed by someone else, and is now offered as a standard component in Max 2012 (current release).

Again comparing Houdini Python to proposed .NET exposure is like comparing Maxscript to Max .NET. It has to be in the SDK level for it to make sense. So it would only have the same problems as the Houdini SDK.

I agree with you that SESI should improve their Python exposure as well. As for QT, I wouldn't really count on it, as its future doesn't seem very certain after the Nokia buyout.

But don't get me wrong, improving existing features of Houdini is always a win for me.

Link to comment
Share on other sites

I don't think using HOM to hook .NET would be beneficial. It has to be at the SDK level. As for it's feasibility, Autodesk said the same thing that it's not possible. One guy single-handedly wrapped the whole SDK in a very short time. You can automate pretty much all of it using tools like SWIG:

http://www.swig.org/

Thus I don't see a reason to use Mono. Why the replacement of C++ with C# is so beneficial? I'm asking because I really don't see it. Note, HDK is not a Max/Maya SDK. It wasn't designed for end-users/third party developers. HDK are the same headers used by SESI internally. I can't see how wrapping 2000 classes of HDK 1:1 with Mono would make my life easier... This is why HOM was created - at least to my understanding. I use SWIG myself, and afaik HOM is made with it also. It works nicely but only if an API is already in place.

Anyway I hate to be like this. Things are changing and new people see new possibilities, that's for sure. I simply don't have particularly warm feelings about .NET/Mono.

Actually Mono was initially supported by Novell. Microsoft doesn't really care about Mono to be honest.

Heard differently, but might be wrong. Yes, Novell has started it, and after a while MS was glad having Mono around for, say, a political reasons.

Autodesk did nothing to Max codebase to have a .NET SDK. Their efforts of revamping the UI through .NET has totally different expectations. Max .NET is developed by someone else, and is now offered as a standard component in Max 2012 (current release).

Didn't know that although I could really expect this: "someone else" knowing Adsk. Albeit wasn't it possible because Max SDK is an API per se?

I agree with you that SESI should improve their Python exposure as well. As for QT, I wouldn't really count on it, as its future doesn't seem very certain after the Nokia buyout.

Well... Maya, Realflow, Nuke and who else, seem to not care about Qt ownership. I'm not saying it's the best option, I'm saying the more time SESI spends for its core technology, the better. Bottom line is SESI seems to believe they have to do *everything* by its own, and this is really small company, and sometimes I'm asking myself if it's not turning against them. Do you know any other company who not only provides complete vfx applications from modeling to rendering and compositing, with all possible simulations/animations in between, but also their own file formats for every single pipeline step (bgeo, i3d, pc, dsm, pic, rat, blut, bclip), three their own script languages, render manager, license server, and finally own GUI library. We all love them for this, but it's quite understandable quite a few things are unfinished :)

EDIT: I think that if you believe it's possible and beneficial, don't stop pushing it! Fresh look good look me saying! You could for example make a test drive wrapping some part of HDK, like a single class GU_Detail :) no, I'm kidding, but maybe some smaller part would be good.

Edited by SYmek
Link to comment
Share on other sites

It's hard to summarize the benefits of C# .NET over C++, but I would say productivity would be one of the many advantages. IMO productivity gains are more valuable than performance gains in most cases.

Also don't get me wrong, I wish there was a great language like C# on .NET without a corporate like Microsoft attached to it.

I talked to some hardcore Windows developers and their opinion was that Microsoft didn't care about Mono. I mean what have they done about it? It was also my observation that Microsoft devs don't seem to comment on anything Mono related, for instance on Q&A forums on .NET.

The guy I was talking about knows Autodesk but they don't do anything for him. They buy/license his stuff sometimes, but AFAIK he doesn't have access to their internal build or anything.

The reason he wrapped the whole Max SDK started as a personal project, and he did only for the reasons I would also like a .NET SDK for Houdini. Productivity gains, etc. Otherwise nothing he does on his .NET SDK is not doable in the original SDK. But now that it's done, he could finish many more tools in less time, and thus more profit for him. Also for most things, you can get away with some performance losses if any. I would rather have a kickass tool that's done 1/10-50 of the time, than have the same tool done much later but works as fast as possible.

I agree writing everything from scratch has pros and cons. I know some places doing this for large scale apps, probably 3-5M lines of code, where you realize it's way too much work even to have your own UI. On the other side, it's all yours and you make it just the way you want. If you had reliable frameworks, most of this work would be off-loaded and you could focus more on the actual purpose of the software.

I might try to provide a small wrapper but not sure if this would change SESI's mind if they already made up their mind on this :)

Link to comment
Share on other sites

  • 3 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...