hello community

my first post in houdini forums and an orbolt based ones

is this possible, we had some compiled c++ modules as extra files and distribute them as .so/.dll/.dylib shared objects, beside our otls, which benefit from that inlinecpp thing inside houdini, to be called inside our locked asset via a python sop?
this way we benefit from current store capabilities for sharing and selling our compiled based assets, and not only just wired networks based assets, and simoltanously benefit from binary codes execution speed and huge performance which is crucial specifically for assets which need real time feedback at runtime in iterative parts of them

or in a general form of question and in short:

can we had fully (or near fully) compiled c++ plugins based on inlinecpp feature of houdini's python implimentation on the store currently?

realy there is no body at sidefx can answer me?

i always known houdini forum as one of the best responsive forums ever, if i wouldn't say the best one
i hadn't no previous post because always i am finding my solutions by searching the discussions and houdini masters always have great gifts here for incomers.
now, in response to my first post, ……. emmmm!

im very serious at developing some ideas for your masterpiece software, which would take along development time, may be 1st, more than one year for me. so i should address some of my concerns first to make a good decision for consuming times in this career

this thread addresses the first one
we can always use of operators as a fantastic visual programing system inside H for developing our ideas. but sooner or later we reach to the point in which these DAs will be just a good prototype of our solution (i mean for big software designs nor for daily works) and just, ability of doing things will not be the whole story.
from a production point of view real time performance of our solutions will be the defacto factor for choosing our tool in competition with other solutions inside some other 3d pakages.

in regard to this, i made this thread to find a possible workaround, while in respect to current architecture of orbolt we have no support for binary and ascii codes to write pure hdk plugins.
we all know for developing great major big ideas in software development world for handling vast amount of data sets, and not just some free or low price tag simple assets, we need capabilities of the compiled codes

hasn't orbolt been made for supporting this kind of vision in its future growth and it is just for supporting some a few tens of dollars things to warm up the community? nor a proper place for major feature releases which surly need c++ code support.
is this code support exist in you future plans for extending the orbolt service functionality at all?

if yes, so we can start developing our assets (plugins) and be hopeful at the time of their completion, in next 1 or 2 incoming years, we would have orbolt support at the same time for delivery.

if no, can my first post be a workaround at current state of the orbolt to allow us using the compiled codes? or it fights to orbolt policy defined by sidefx and we should completely leave this play ground

if it not be possible, for big software ideas development, other pakages and their plugin writers always will be the winners, at least in short term.
simply because their compiled codes runs times faster than cooking our feature rich H assets

if i am wrong, i'll be glad to see your point of view too

thanks to every one at SESI who answers me.

cheers

Hi, sorian,

not from SESI, but as far as i know inlinecpp requires you to have a compile ready environment in other words its a good feature for developers, but not for final release of the plugin.

I might be wrong thou

Regarding dso/dll/so there was a shader with external files hosted elsewhere or i believe you could script your otl to unpack / install. But then there should be a versions for at least production builds (which wouldn't be pretty).

hi owlYzarc,

you are right,
actually what im following is kinda supporting a concept more than assets on orbolt. may be better name it completely a plugin.

a compiled plugin always will have it's obvious precedence over an asset. which is its increased speed. if you had any experience in software development you know this. a good designed plugin in compare to it's counterpart asset, which has some hard coded python sops inside, can run at least 100 times faster and depending on your design choices even this number can grow higher to multi hundreds of times.

caution, im talking about assets which can be kinda a major feature, and this speed access is crucial for them. otherwise they get unuseful. assets which are able to convert H14 to H15. this huge speed difference is not negligible for any developer and no programmer never ever can close his/her eyes on it.

and don't say recompiling it for compatibility with production builds wouldn't be pretty. its natural nature of plugins writing, and just sidefx should find a way to manage it somehow.

reason of this request of me for supporting this type of plugin support in assets store, is just existence of this excellent feature “inlinecpp”. sidefx did a great job on this. using pure c++ coding syntax inside houdini. ppppppuuwwah. this is fantastic. all other 3d packages must nail down here against houdini. its very disappointing in which beside existence of this powerful feature, we are not able to use it inside our python sops and consequently inside our assets designed for store.

this way developers doesn't need to leave their comfort zone for forming their idea inside beautiful environment of H.
and at the end of the day they do a complete rewrite inside their c++ IDE
with respect to store definitions we just ignore this last step. but please don't tie our hands for using python sops that can call cpp functions defined by inlinecpp. it opens the door to a whole new world of possibilities.

and, yes, managing this on orbolt, technically has managed supporting of fully compiled cpp plugins on store too. which would be more more pleasant.

houdini's old user base are mostly good technical mans. if you let them be more free for developing their ideas, you will more quickly extinguish some 3d civilizations out there (you know what i mean)

again, remember “more than 100 times faster execution speed”. i swear it will blown orbolt growth.

so we can start developing our assets (plugins) and be hopeful at the time of their completion, in next 1 or 2 incoming years, we would have orbolt support at the same time for delivery?

Just pinging this thread – I'd like to know if we can use the inlinecpp module inside our Orbolt assets, or if this is planned for the future. I can imagine there are potential issues using includes and link_dirs, but with some restrictions this could be incredibly powerful.

You can use inlinecpp module for your custom code inside Orbolt assets. Caveat is user will need to have their build environment setup properly. This is easier on linux/osx as they include the compilers; on windows user will need visual studio. Ideally you'd want the user to build the code on their machine. While you can distribute so/dll files with the asset, you might run into binary compatibilities so it's something to keep in mind.