davpe

to make this info a bit more complete, you can also time offset alembics directly on alembic node by having an expression in Frame parameter. for instance $F + 10, or so...

what error does it say? mine wasnt working one time bcs GPU drivers.

can you do HDA perhaps? not sure whether that works with lights and stuff but maybe worth trying... in case you havent yet

actually, i was wondering about doing the same thing not too long ago, when I needed to do a camera timewarp. see the hip file bellow. in short, you need to extract a camera transform into an oriented point (with N, up, and all that jazz), and then use rivet_SOP to drive other objects around with this point transform. works quite well for me. cheers. camera_timewarp.hiplc

Sort SOP it can reverse, or sort points / prims by different criteria in your case i believe it would work well combined with resample SOP (it generates @curveu attribute that can be used to sort points)

It depends what and where you wanna do but in general: 1) in most cases, point, prim and detail expresion functions work well: point('../sourcenode', @ptnum, 'attribname', 0); 2) in some cases, simple @attribname will work. 3) some nodes will take attributes automatically if they have an expected name and class (i think @width point attrib is automatically picked up by polywire SOP for instance) the first method is overally the most reliable.

Hello everybody, I became tired of dealing with various viewport bugs in Houdini, still hoping it will go away one day. On the other hand, I guess even Houdini has to have something that totally and completely sucks Anyways, my biggest issue is with displaying textures. Sometimes I am unable to display any textures unless I restart Houdini. Other times, textures are sort of displaying but are not updating - I mean if I assign a material to an object, there's no guarantee it will actually display in the viewport. And then it pops up 5 mins later when I'm doing something else. Closing and opening a new viewport only helps sometimes. There is bunch of buttons that promise updating viewport materials and textures but they seem to do nothing. This is SUPER annoying and I'm looking for some workarounds (if there are any at all - I'm trying to figure this out for years with no success). Thanks for any suggestions. cheers.

sure, it depends what you trying to render. I was able to render some very large volumes in no time with Karma. Some other tests performed quite poorly on the other hand. Anyways, my main concern wasn't speed - more than anything else it was bugs, various glitches (in Karma and LOPs in general), stability issues and missing features that made me decide to wait for some time until Karma becomes more production ready. Having said that, I am sure Sidefx have been working hard and many things may have been improved in last few months (and I might want to have a fresh look at it). as for Redshift - RS certainly is one of the best GPU renderers today you can get your hands on. However, if you do a lot of heavy stuff, or you want to rely on procedural texturing, RS looses a lot from it's appeal.

file names should be generated automatically by filepattern TOP as a pdg attribute. if you middle-click a workitem you should be able to see them.

As far as i know, Karma currently is not consistently faster than Mantra (means it is faster for some things, but can be even slower for different things). so far, my superficial experience with Karma made me put it aside for now, as it still seems to be a very unfinished product, unfortunately. i'm still very excited about Karma thou, and maybe Houdini 19 (or 19.5, 20, ...) will bring some significant updates to it's stability, speed, features and general user experience. Up to that time i'm gonna continue living in Mantra world. I have no solution for your "not being able to render stuff out" issue, but it sounds like Karma to me. Also, I hope to read some optimistic posts in this thread

if i understand correctly, you've got like 1000 blueprints and you want to say - hey, blueprint number 568, set your height to 12. in that case, wrangle SOP is your friend: if(@primnum==568) @height = 12; if you want to edit a bunch of prims you can chain them: if(@primnum==568 || @primnum==654 || @primnum==33) @height = 12; i'm using @primnum in these examples (which refers to the particular primitive number) but you can use any attribute: if(@P.x>10) @height=12; (modifies all prims with X axis position value > 10) obviously this becomes cumbersome if you want to edit more than few values. in that case you can first group them and do the operation on groups (the group is called "abc" in this example): if(@group_abc) @height = 12; these are just some trivial examples of how to manipulate subsets of data but possibilities are endless. you can get very creative here with arrays and loops here, you can filter things by incomins attribute values (names), it's location or a distance from something, by it's size, by user defined tags, you name it.

hm, heightfields can be slowish in high resolutions but waiting 30 mins for your scene to load sounds like a complete nonsense for any houdini scene. even with heavy terrain scenes i can get it loaded pretty fast if i cache things on disk properly (lets say a couple of minutes in case you use rather slow and older workstation - anything longer than that means you should think of optimization :) not sure what exactly is your workflow but here are a few tips to make things move faster: - if starting from HF map, it's not really a texture resolution that makes it slow, but the voxel count it is sampled into. maybe you oversampling your stuff a lot? try to double the voxel size and see if it actually makes a lot of visual difference - speaking about resolutions - experiment with how dense your HF truly needs to be. consider from how far you will look at it. proper texturing and normal maps are your friends here. - if possible, start really low res and gradually build up details in multiple stages. don't try to generate the final result using one erode sim. - after each erode sim or other time consuming operation, do a "checkpoint" cache to disk. don't rely on freezing the sim. it doesn't really work as it seems bcs each time you open the scene it wants to recompute the result. which actually makes sense - storing multiple hires erode sims in the hip file would make it huuuuuuuuge! (i suspect this also might be a reason for you having everything so incredibly slow) - be aware of paint nodes. with default setting the paint cache is actually saved with the hip file, making the process of saving very slow, and hip files BIG (like gigabytes). you don't want that. masks typically don't need to be too detailed so make the HF lowres before painting and then use it to mask the hires one. also, paint node can be made "live" all the time but that again can slow things down. i think in the latest Houdini release there is something called heightfield draw mask SOP (instead of paint mask). this seems to be much faster and lightweight alternative. - if heightfield is too big, do an init lowres sim on the whole thing first to get the larger scale features in place, and then split it into multiple tiles and work fines details on those separately. then you can merge and blend them back together ( must admit thou, blending is sort of meh, you need a generous overlaps to avoid visible seams where two tiles meet) hope that helps. cheers.

thanks anim, user data thing sounds promissing. will look into that.

no sorry, I meant like this, for instance: 1. in OnCreate: path = hou.pwd().path() 2. in PythonModule i want to access this path string. this is a trivial example, I'm just looking for a general way to exchange data between HDA scripts triggered on different events - if it makes sense.

hi guys, I'd need to get one step further with this and read the variables produced in OnCreated script by different scripts in the same HDA (Python Module). Spent a day reading through Houdini docs but can't figure out how to do that. help appreciated. D.