Hi all!

I'm about to buy a Houdini Indie license, but i couldn't find any information about whether or not this comes with the HDK ? I don't see why it wouldn't, since Apprentice does, but i just wanted to make sure.
What about if i load a plug-in compiled with Apprentice, inside Indie, will that work?
Thanks a lot!

David

I will add another question:
Can we develop custom Houdini Engine plugins (in C++) for other applications with Houdini Indie or is it limited only to already existing ones (Unity, Maya)?

The HDK toolkit comes with every install of Houdini.
You can find everything including examples in $HFS/toolkit.

$HFS or Houdini File System is the envvar to the Houdini install directory. Straightforward on Windows/Linux as you pick that install directory.

On Mac $HFS will look something like:
/Library/Frameworks/Houdini.framework/Versions/14.0.132/Resources/toolkit

If you use shells, you will want to source houdini_setup in $HFS to set up your shell environment. Customize to your needs.

That's great!
Thanks a lot Jeff.

I have to say the code examples are just a goldmine!!

-d

The other questions seem to be about portability of hdk custom nodes you write yourself.

The answer is generally yes. When you write a node that opens up in Houdini, it will work in Indie for sure and visa versa. If you write a custom node that is used in an asset that is loaded in to Unity/Maya, that too will work.

Engine will run Houdini underneath so any operator should execute as it did in Houdini/Indie.

jeff
The other questions seem to be about portability of hdk custom nodes you write yourself.

Nope. I'm curious can I build my own Houdini Engine with Indie license or will it shout at me that there is no license like in this topic -> https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=31347 [sidefx.com]?

jeff
The other questions seem to be about portability of hdk custom nodes you write yourself.

The answer is generally yes. When you write a node that opens up in Houdini, it will work in Indie for sure and visa versa. If you write a custom node that is used in an asset that is loaded in to Unity/Maya, that too will work.

Engine will run Houdini underneath so any operator should execute as it did in Houdini/Indie.

hi jeff,

does this mean, we can upload these assets on orbolt? assets with some custom c++ based operators inside. (obviously author should update compiled portion of the asset, with every houdini major release for diffrent platforms).
if no, is there any plan in orbolt future, for these kinds of support?

may be compiled binary codes, defeat orbolt policies, ok,
so, what about uploading custom operator's source code, and let the sidefx make them compiled. is there any future plan.
i asked this sometimes ago on orbolt section of forum,
but without any reply there too.
https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=34307 [sidefx.com]
is this a forbidden question?

i hope someday someone somehow do something and give us some insight about this.

That is one restriction with Orbolt is that you can't embed custom written operators with HDK.

The key issue is having to support all the various platforms and have these assets compile with each release and what to do when a custom operator fails to compile…

jeff
That is one restriction with Orbolt is that you can't embed custom written operators with HDK.

The key issue is having to support all the various platforms and have these assets compile with each release and what to do when a custom operator fails to compile…

oh my God, finally a reply thanks jeff.
actually im thinking in two ways, every individual developer can choose either of them according to his/her preferences.

first one:

developers, who want their source codes stay hidden from others and completely private for them.
so they do not account on orbolt service. they compile their codes and do whatever it needs for making the product commercially available.
registering a copyright, advertising, marketing, selling and so on.

second one

developers, who want benefits from orbolt store prominences. so they only have just one selection, uploading the source code, as i mentioned before.
and sidefx enters in an agreement with developers in which, it will have the right, for making every changes inside the codes, if any compatibility problem happened.
actually at first release every thing logically should go fine, and individual developers must deliver a workable asset without any problem for every platform.
this way the majority of codes which do the actual job of the plugin/asset will remain unchanged for future houdini releases.

next compilations will fail, mostly due to some drastically changes of the compiler, or drastically changes in houdini architecture or the OS.
and there, if the asset's author not be accessible for addressing the problems, sidefx uses its own right for changing the uploaded codes.
actually im talking about some kind of collaborative works between sidefx developers and indies.

one issue, might be the growing number of assets, which will impose some difficulties to sidefx, and make things unmanageable with your limited resources.
so i recommend another suggestion.


establish a qualifying system on orbolt

this way just those assets will be accepted which have passed certain conditions and sidefx recognize them as useful assets, capable of taking houdini one more step forward in the market and have enough worth, so sidefx developers work on them, if any future compatibility issue occurred.

might be a little unfriendly, but it makes thing manageable for you, and limits the number of HDK based operators and just the best ones will be allowed to place on orbolt
recognizing this type of assets will not be very difficult task for SESI, their code size mostly is huge, and the type of work they do, is unique,
even, individual expert developers can understand it easily, and make a true decision to start, even before starting their development.
assets, which will take month after month, or even some years of research and development time and not just some days. they will be placed in qualified region.

by imposing this limitation, the number of people involved in this program will be limited too. even in long term. may be 5, 10 , 30 person, and im sure. there will not be hundreds of people consume their time in a long period of time for making something new, functional and unique.

but possibility of this limited HDK based asset support, will persuade the individual developers around the world, which have some novel ideas to start their development, and for some months/years be as coworkers of sidefx developers but far far away from sidefx offices
at the end of the day, your limited service will support a limited number of people and assets, but those limited number, might make some big changes and deliver some brilliant ideas which can play a game changer role for houdini.



a short talk about vex\cvex

vex is an awesome tool inside houdini, i have never experienced something similar in other packages.
a built in compile based solution inside a 3d app. this is a fantastic tool. from the last version of houdini, we have the possibility of geometry creation, we have the possibility of some pseudo object oriented programming. these make vex coding more acceptable for doing more things.
but in a hard coding process, it shows its own limitations too.

we haven't access to multi dimensional arrays, we haven't access to some advanced data structure types( dictionary or maps, etc… ). some times we need tools for controlling and manipulating viewport actions. in huge developments, everything doesn't happen just inside operators.
for example if we want to implement an advanced sculpture for H, we need something like Zbrush advanced transform handle, or if we want to bring in some advanced nuke functionalities inside H compositor, then we need, capability of drawing some markers or graphical elements over composite view, we need fully support of input devices, mouse, keyboard, tablet, for running our callback function, in response to input devices events. we need some low level opengl calls for drawing our own specialized handles and tie those callbacks to them.
these equipments will be used for making houdini more and more powerful, not for making assets just for delivery to other DCC apps via engine.

vex is based on a compile system, so can we expect these low level functionalities from vex, which other compile systems can do. if it is, then we stick to the vex and do, majority of our works inside houdini without refering to HDK. it just needs some more years of patient, till vex be more matured.

are these functionalities technically possible in vex at all ?

No vex technical behind?

may be entering, in answering to questions like this, reveals some of the in progress works of incoming versions of houdini. features which should be hidden until release time. and this is the reason why sidefx guys hesitate give us some technical behind info.

anyway, thank you SESI.
best wishes for you.

The answer is generally yes. When you write a node that opens up in Houdini, it will work in Indie for sure and visa versa. If you write a custom node that is used in an asset that is loaded in to Unity/Maya, that too will work.