sebkaine

well my advise for VR HMD / Viewport / realtime stuff like this , do yourself a favor and forget Houdini and go with unity / unreal + hengine if you can check out all the stuff from Simon Verstraete it's pure gold Tutorials | SideFX

https://www.tokeru.com/cgwiki/HoudiniOculusWip some good info. i would say no you can't by default. but you can setup a 6 cam rig with a 90 fov for each cam, and stitch them with a batch process using isixpack or any other cubemap2latlong command line tool. if you want to work directly in VR like in maya / blender where you move object and see all directly in your hmd , i don't think it's possible.

It would be nice to have a new Houdini Engine licensing policies. Today if you are a small company with floating license. You have to pay $795 per year per machine which is perfectly fine. Paying a fee when you do use houdini in batch mode, is perfectly fair. You need to use mantra / karma / or any Dop / Sop processing on your farm it's ok to pay the right to access Houdini. But when you need to just render a scene in an external engine, a scene that just contain loaders to .bgeo / .abc / .vdb files in Arnold / Vray / Redshift / Octane, i don't find fair to have to pay the full price to just open the scene and send it to the engine on the renderfarm. I just don't render or process anything with houdini, i just send my scene to the external render. Thus each time i said in place i work that it would be better to switch the render to houdini and stop using the other software i would not name, i always get this answer. How much it cost ? And in fact when using arnold for exemple which is $500 per year, you have to add the $795 cost to each arnold license, thus $1295. so it cost a lot More. So they always said, why do you want to pay 1295$ per machine while it cost only $500 with the other software. Why do we should pay the right to send our scene on the farm $795 ? I could do full .ass export for each scene but in small shops where there are not strong pipe dev or houdini dev it's rarely an option. And when company use a mix of render engine you add another layer of complexity. My point is that it would be great to have - Houdini Engine , an engine that process data or render image using houdini tech and that cost $795 for accessing this technology - Houdini Batch which basically would only open a scene and let the external render engine render it, be free or cost much less , because it do much less. Cheers

i have bang my head a lot with some shitty mesh coming from C4D. the most effective way i found, that work more than 95% of the time was to. loop each pieces, close them, convert to vdb then compare N with Grad and invert the direction if they are not the same. it might work in your case. clean_normal.hiplc

i don't know C4D very well, but i use this method with octane. - i export an .abc of my curves with @Cd, @v, @width store as a point attribute on my curves - i open it in octane standalone where i prefer to prepare my orbx instead of using the houdini orbx exporter - i assign the shader in standalone with the color vertex attribute node to read Cd - @width and @v are directly recognized by octane - i save the scene as an .orbx - i load the .orbx directly in C4D with the orbx loader For redshift you might just need to export directly an .rs proxy and load it in C4D

another exemple hip with primintrinsic and spareinput methods. ( thanks papicrunch for the looping tips ) copy_timeshift.hiplc

Thanks for you feedback guys, again i don't agree with all of them, and that's the hard part of doing software where you need to please very various user pool. I will not continue to rent to much here about solaris, because it is the feature request topic. That would be better to create those debate in a solaris section, where people could argue about the pro and the cons of USD/Solaris. Feature request wise just having parity between the layouts nodes in SOP and SOLARIS would be great. Because if you design an env for a unity realtime game that you want to combine with Hengine, why bother with solaris ? But if you want to access all the cool new stuff you have to use solaris, having to do so feel like something not elegant and straightforward imo. Cheers E

This sum up exactly my point. modeling / layout / texturing / rig / anim / geocaching should remain agnostic and stay in a common trunc, where you have choice on what geo format you like the most. then when all is set you can now decide where you wanna go. - Unity with Hengine for low / mid spec interactive XP. - UE with Hengine for high end spec interactive XP or Cinematic - Traditional rendering context for fast and simple rendering with popular engine : arnold, octane, rs .... - Solaris context when you want to be able to work in an efficient way with multiple users on complex shots with lots of iteration and many redundancies between shots. USD as geo exchange format is still very interesting imo what Frederic Servant show at 4:00 is really cool and i 100% agree with you on that : Arnold USD loader you can just grab directly an .usd file with full geo plus metarial assignation inside the renderer. You use a subset of what usd offer but you don't have to deal with all the features and all the complexity. it's like doing C++ but with restricted set of features, no polymorphism, no operator overloading , no multiple inheritance are allowed, you just use simple class and inheritance, because for your needs , you need to keep things simple. Thus You just grab what you need and you can then limitate the level of complexity you accept to pay.

Hi Vince i hope you have great hollidays my friend, and thanks for sharing your detail pov about USD. There are points where i agree with you and other where i am not. like i said : - ability to exchange assets between DCC's is a good idea. - layering the work of all departement is also a good idea when you have big team of artist. But those advantage come at a price, the price of a very complex scene description language, that imply a specific and time consuming way of working, that will only be rewarded if you are inside of a certain spectrum of CG production. I have the belief that people in an other part of the spectrum will only loose time and flexibility by going the USD way. With solaris you can create complex light rigs , infinite versioning etc .... but you also have a LOT of workflow methodology to follow to be able to do so. And that methodology cost you time, and thus money. And if you are not working on big show where at least 100 artists are at work together to create at least 200 shots, i am not sure you will get the reward in efficiency that you have expected when working with solaris/usd. My point is that pre solaris we had mantra, now that karma has arrive mantra will be very soon stoped and thus legacy. So now karma is the way. But karma is solaris/usd exclusive. so for those who don't want to use USD, we don't have any default render engine. For me the fact that sesi push us to do layout / rendering with .USD is not a good thing. because again the complexity and the price to pay to get the benefit is on a Katana level of production. Sure you can do Marvel or Pixar movie in Katana. But using Katana to do some dirty commercials or motion design animation or even layout a sets for a low sepc game or a AAA game is a non sense. But when using solaris to do so i have this feeling of using the wrong tool to solve a simple problem who don't need such a high level of complexity. My point is that the beauty is to have choice ! - you can use Solaris / USD if you work on the spectrum of production that will reward his complexity. - But you can also have the choice to bypass it to stick to . GLTF only or .FBX or .ABC only if you prefer to. I would really prefer to stick in SOP for my scattering / level design task, then if i need to i could then conform and import them in a USD workflow. I have no problem if people think it is a better idea to layout directly in USD, but at least i would like that the set of layout tools in SOP stay on par with Solaris. Cheers E

I understand SESI is pushing at 100% USD and Solaris, but USD has been created to solve certain user case, and the many layers of complexity it adds, is not always needed for freelance and small shops. In game where you want to work with FBX / GLTF for ex why bother with a tools that is basically interfacing .USD description ? Thus i would love to see : - a SOP version of Solaris Layout Node https://www.sidefx.com/docs/houdini/nodes/lop/layout.html - a SOP version of Solaris Edit Node https://www.sidefx.com/docs/houdini/nodes/lop/edit.html The ability to just create my small lib of GLTF / FBX assets and scatter them with all the modern tools added in solaris. Also An improved version of the "use physics" option in SOP would be useful ( kinda like of Paul custom labs tools ). Then the only thing i get is just a bunch of object with an id and a point cloud with xform, that i can export wherever i want with Hengine for ex. Don't forget that .USD was created by pixar to solve problems meet by a company that has maybe 2000 employees and work on full feature film with a full time R&D team. .USD simplify the layering of various dpt working together, and the exchange problems between DCC's, but we don't all have these problems. Not everybody will want to pay the complexity price of USD to get the advantage it offer. When doing 30s Ads with agencies that change their mind about 1000 times per day i am not sure you need to add USD in the mix. As i work with small team, under agressive deadline, i like to keep things as simple as i can. But maybe it's me that is wrong and missing the point ? Cheers E

i would use hair curves or ribbon geo trail to art direct the trail. if trail are straight i would then worldcenter the head of the trail for the pyro sim. and then inject density / speed created from trail in a sparse grid. trail ribbon going the after burn way is really old school in houdini. BUT if you really want that you need a cvex vollume shader that pcopen per point attribute at rendertime. this might be useful to achieve what you want : https://www.orbolt.com/asset/SideFX::pointcloudvolume

i would try to feed the render engine directly without doing any intermediate step inside maya. if you use arnold render, i recommand per frame alembic sequence and direct load with the arnold stand-in for geo, points, curves. https://docs.arnoldrenderer.com/display/A5AFMUG/An+Introduction+to+Stand-ins and arnold volume for vdb loading. https://docs.arnoldrenderer.com/display/A5AFMUG/Volume

a small exemple that might be useful with it. extrude.hiplc

Great stuff Vince i didn't know this tool exist , very interesting especially the zRemesher + Blendshape connection.

ahah great guys ! whisky it is ! for quad remeshing algo , the best imo is zbrush cause it give you the ability to draw topology guides directly from cv's. quad remesher from exoside is in second place. and i think this is the same guys that coded the two. at least in the early Zbrush release. but the big plus is that you can run it throw SOPs procedurally, and Zbrush can't match that.