sebkaine

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.

ahah this exercices is really addictive ! i finally got something good enough , i have refactor a lot just polyexpand + quad remesher , i think you have enough to mimic the reference, the only part that need extra work is how you compute the displacement map, where you need to precisly evaluate edgedist instead of my old school att transfer. expand_remesh_003.hiplc

That's cool vince ! the hardest part would be to relax the edge loop in v direction in order to have a match topology between each patch for merge. Quad remesher is nice , it cost a litlle but it offer remeshing qulaity you can't match with vanillia houdini tool. I try to combine polyexpand + area isolation with voronoi + quad remesher. it's not bad , but the topology is not perfect like the reference. i really feel that poly is clunky for those kind of work, i really prefer nurbs for that kind of stuff. for exemple just the clean flat topology is hard to get, and we haven't even talk about beveling between each torus. I'm curious to see if some modeling expert can come with a fully working solution. Cheers expand_remesh.hiplc

Polyexpand is also interesting but not perfect. this question is a good rubik's cube for the brain I would probably go for a polyexpand + quad remesher path, but this problem need some love if you really want to get a clean edgeflow polyexpand.hipl c