davpe

from what i see you just need to remap @curveu attribute: @curveu = fit(@curveu, 0, 1, 1, 0); // by adjusting numbers inside the brackets you drive the resulting thickness and then do your thing with @pscale and it should be it

ok i don't wish to fight and i certainly don't think vfx and games don't have anything to learn from each other. quite opposite actually. i just did not understand how your comment relates to the original question, which was how to do this stuff in houdini. i posted an example with a short description how i did it. your reaction was UE and Eevee is more interactive than Houdini. i guess everybody can agree on that but what is your point, i don't know

Yes, Unreal and Eevee are realtime engines and it's main feature is speed. Both also come with some painful limitations steming from it's realtime nature, which prevents it to be used as a reliable film production tools (so far). But isn't this thread about how to make a detailed ground to match the plate, in Houdini? Discussing rendering capabilities of UE doesn't seem to be relevant to the original question. I don't know exactly what you mean, I guess that's a workflow specific to realtime rendereres. Seamless blending is typically achieved by making the cg extension look as close to the real thing, and then by compositing

hi, 1. the issue with mplay - not sure what exactly is it complaining about but my guess is you missing a codec or something that you need to save the video file 2. the warning on Mantra ROP is just a note that a default light have been created automatically as you don't have any lights in your scene (with no lights render would be completely black) 3. if you render from Mantra to disk, you'll end up with sequence of frames anyways. it's common to use some compositing program if you want to save it as video.

you mean this?

i think, if you want to do something custom (not using pre-made textures) the good way to accomplish this is to build as many shapes and details as possible on SOP level (faster tweaking and more straightforward). then use computed geometry maps to drive finer details in the material network. This general approach typically works great. If you need lower res geometry for rendering you can always bake everything into textures (but Houdini and Mantra typically deals fine with heavy geometry). Some time back I did this thing as a practice. The tank is textured with Substance painter but the ground and other stuff are modelled and textured procedurally. I know this is relatively simple looking ground texture, and things get more complicated most of the times, but the approach would be very similar. Only more layers. If you can't push it far enough procedurally you can always pepper it a bit with scanned details.

I think, in the list at your picture, there are always listed all possible parameters that can be attached to all kinds of objects. You can do some obviously not working attempt, like adding some light related parameter to a geometry object. That's not applicable (you can still add it but it will just sit there doing nothing - as anim already pointed out). And that's what I think you did with pixel samples parameter, and perhaps with refract depth parameter too (never tried). Those are only applicable to a Mantra ROP, not to geometry node. Others may be only applicable opposite way (render visibility for instance doesn't really make much sense to Mantra ROP), or are applicable both ways (Shading quality, ray samples...). I agree it's confusing you can add parameters that aren't applicable to a particular object type (often can be hard to guess).

you can take a look at this video bellow. shader baking starts at ~ 17 min. you can bake multiple objects by merging them into one and baking that.

Hi, my opinion is this: while I can agree to some of your points and definitely many things could be better, I guess it's just silly to complain about Houdini not having the same strong points as C4d, while demanding to keep the strong points it already has. I could too do a list of another 50 things that bug me, and you can do such a list for any vfx application, but let me rather contemplate on why no 3d app is never perfect. First - today, alongside with Blender, Houdini seems to be the fastest growing general purpose 3d creation platform. With every release SideFX brings incredible amount of improvements, and is often introducing innovative tools that make really difficult tasks easier (or even possible). Very few other developers can do that with such rate. Ultimately, these improvements are saving me much more time and effort than having better spline tools or more polished interface. With more polish, we'd have less power now. Polish takes an incredible amount of time to do right and I'm glad Sidefx gave way to innovative features rather than new icons or something. Honestly, complaining about not having a scene thumbnail, or an indication of not having saved my file since I last clicked, feels like a joke to me in this context. Second - it all comes down to what kind of user are you and what kind of work you need to do. Many people are very visual, they pay a lot of attention to aesthetic and design of everything, and they don't want to think about anything technical. They don't even need to as far as they do small scale projects that aren't too complex (technically). In this world, C4d is perfect - very slick, polished, super user friendly and as easy to use as possible. But then you see veteran users migrate from C4d to Houdini precisely because - C4d developers spent an enormous amount of time making their product polished with great user experience, but hey, this new project we've just been awarded is simply not doable with it's tools and workflows. I mean, it's not C4d is bad, it's just not been built to be used as either a heavy duty framework, nor a coding paradise for technical artists. On the other hand, Houdini emerged exactly from that environment thus it's obviously strong in different areas, and you can't really expect the same experience with scene thumbnails. It's like you're used to driving Porsche, but now you have a 4x4 - you can use any of these cars to drive to work but it's silly to expect the same driving experience (or to drive Porsche offroad). I don't mean to imply we shouldn't call for feature improvements or not to look at other apps. If it feels important to you, send them RFE. But I personally hope they will keep spending development time on innovations and making things solid, rather than adding convenience tools and polishing up interface (even thou Font SOP and working with curves is killing me too sometimes). Cheers.

well, hard to say then. then there must be some other reason why it yields several times bigger output. perhaps if you can share an example scene? btw did you also try File>Export>Alembic? (instead of ROP Alembic output). just out of interest

as was stated before - if the file is bigger it means either there is some additional data, or the data has been saved in a different manner. Alembic is just a framework, and is always the same regardless the application you're using. Just by looking at your numbers - you said 960f takes 119mb from Maya. now calc this: 119mb * 960 frames =~ 114,000 mb, which roughly matches your 106gb. the calculation i did is the difference between saving non-deforming geometry (geo is saved once and then transformed on every frame) and deforming geometry (saves full ~100mb for each frame as it presumes topology is changing). I suspect that is your issue. cheers.

hi, there is a Fuse UV SOP that you can use to sew pre-existing seams, but it doesn't work as conveniently as you wish for - it works basically as a normal Fuse SOP and fuses any points that are in proximity radius. So you have to manually align uv islands first (and maybe group them) and then fuse them. Kind of sucks, but will do the job if it's not a heap of seams you need to sew. For other kinds of edits, you can use UV Flatten SOP, and say "Preserve seams" and "Preserve layout" - that should keep the original uvs intact, and you will be able to do edits on top of it (with exception of fusing pre-existing seams which is a shame). But to be honest I found the "preserve features" in this node not to be working great every time (it always tries to remove uv distortions so if the original uvs were distorted it will still relax them a little). Most of the time what I do in such cases, is to split the geo and work only on pieces I need and then merge them back together. I agree UV Flatten SOP could use some more polish. Maybe a RFE?

i think it's impossible to say what's wrong just by looking at those two pictures (can't even see what's the issue to be honest). try to be more specific. maybe start with what renderer are you using, and what exactly is the problem ("flickering" is quite vague description).

Generally the more collaborative is the environment you work in, the more sense make things like USD. In my humble opinion, at the current state of LOPs, and especially if you work alone, i guess there is currently little to no benefit from the new workflow. True LOPs introduced some very cool features that will eventually be useful for all users, but from my trying out it seems LOPs is not yet polished and mature enough to be used reliably - at least not for most people/studios. It's certainly just a matter of time thou. Everything about LOPs looks very promising and sidefx typically delivers a solid stuff. So I'm staying tuned

hi, that should be fairly easy. on your original geometry with uvs, use "Atrribute from map" SOP - that will do like a point colors, based on the uv mapped texture you bring in (so the geometry resolution plays a role here). then attribute transfer the point colors to your remeshed geometry (attribute transfer SOP) - this expects the gemetry shape is not changing much as you suggested, otherwise the workflow would be a bit different. then on your remeshed geometry use a point wrangle with a code like this: if(@Cd.r>0.5) @group_mask = 1; and that will do a group called "mask" where the map intensity is more than 0.5 (borrowing a red channel here but it doesn't make a difference with grayscale maps). and that's it. cheers. D.