for extra events handling:
https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=27032&start=0&postdays=0&postorder=asc&highlight=script+job+maya [sidefx.com]
Found 49 posts.
Search results Show results as topic list.
SI Users » Event when Hip is Opened
- sorian
- 49 posts
- Offline
Houdini Indie and Apprentice » Houdini Indie and HDK ?
- sorian
- 49 posts
- Offline
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.
anyway, thank you SESI.
best wishes for you.
Houdini Indie and Apprentice » Houdini Indie and HDK ?
- sorian
- 49 posts
- Offline
Houdini Indie and Apprentice » Houdini Indie and HDK ?
- sorian
- 49 posts
- Offline
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 ?
Houdini Indie and Apprentice » Houdini Indie and HDK ?
- sorian
- 49 posts
- Offline
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.
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.
Houdini Indie and Apprentice » Houdini Indie and HDK ?
- sorian
- 49 posts
- Offline
jeffhi 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.
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?
The Orbolt Smart 3D Asset Store » Inlinecpp and Store Digital Assets
- sorian
- 49 posts
- Offline
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.
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.
The Orbolt Smart 3D Asset Store » Inlinecpp and Store Digital Assets
- sorian
- 49 posts
- Offline
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
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
The Orbolt Smart 3D Asset Store » Inlinecpp and Store Digital Assets
- sorian
- 49 posts
- Offline
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?
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?
-
- Quick Links