davpe

there is a scale manipulator. you just have to press E key. that's the way it is. don't ask me why.

hi, you've got a few options here. 1. store an primitive integer attribute for each page number, then use that in the shader (bind VOP) to switch between different textures (probably the most straightforward solution) 2. store a string attribute containing the desired texture name (or full path - that would be simpler to implement in shader) per page, and feed that into the texture path entry on texture VOP in shader (again with bind VOP). 3. use material style sheets to override a texture path per page (this would be a slight overkill for this kind of thing thou

it sometimes happen that applications convey residue attributes with abc file, or normals are scrambled. so check for that and delete any attributes that you don't need. also, if not using Mantra for rendering, make sure your abc is not imported as packed geometry, and that polysoups are disabled. dunno if octane supports any of those features. unsupported geometry type would definitely result in wrong looking render.

it depends... material names in shape names would be obviously a good thing to have but from my experience, modelers just don't name things as you'd like them to, and it seems to be a waste of everybodys' time to force them to. so I typically just want to have some meaningful names saying what things are, and most importantly, not having objects that are supposed to be made of different materials, fused into a single shape (that's obviously an issue that can only be solved by cherry-picking polygons by hand). Then I typically do attributeStringEdit SOP to add material names to groups of objects. For instance I might want everything called "wood" to have the same material as objects called "planks" and "beams", and also "Beams", "Beam", etc... So I take all these and add "woodMat" at the end of their path names. And then in the wrangle I just filter "woodMat" and assign the material to all these objects. And then the model is likely updated several times, with some new shapes, or some shapes named differently than before etc. So to tackle that, I usually have bright green emissive material (just something really obvious), and the last line in my vex will say: if(s@shop_materialpath == "") s@shop_materialpath = '/mat/green'; so that any shapes that were not picked by my pattern matching for any reason, will render this stand out green color to be immediately noticed. so that's generally my usual material assignment workflow for assets made of many objects. this or stylesheets if objects are packed and I can't unpack them - but mostly I prefer wrangle workflow as I find it more straightforward and it can typically do all I need.

as I said, stylesheets or vex are both good methods. vex allows very straightforward assignments by matching @path names. stylesheets allows assigning materials to packed geometry and more complicated assignment patterns. with simple vex assignment, you'd go like this (in primitive wrangle SOP): if(match('*brick*', s@path)) s@shop_materialpath = '/mat/brickMaterial'; if(match('*wood*', s@path)) s@shop_materialpath = '/mat/woodMaterial'; if(match('*metal*', s@path) || match('*METAL*', s@path)) s@shop_materialpath = '/mat/metalMaterial'; ... this expects a meaningful naming convention, obviously. if you have a good naming, you can specify just a few patterns to batch assign materials to many objects at once. all in single wrangle node. this is also the fastest way to assign many materials I guess (in terms of processing). this method also works well with attributeStringEdit SOP - if you have slightly messy naming of alembic paths, you can fix/unify them first with this SOP and then batch assign materials with vex as shown above.

stylesheets are pretty awesome and allow complex assignments and overrides based on groups, attributes, object names, scripts and what not. also, you can use single wrangle SOP to batch assign materials to many pieces of an individual object, by string matching group names or string attribute.

well this is a bit odd what you doing. not sure what the result should be. technically, you cannot evaluate an intersection with a point in space as there is no surface area to be intersected. in sops it gives you some result but I haven't found it meaningful in any way. anyways, if you want to use intersect in shader you can use the same Intersect VOP as you have in SOPs.

very much depends what is your workflow... if you build the stuff within houdini, everything is much simpler as you can utilize various procedural techniques to get uvs with little effort even for complex geometry. long cables for instance can have repeating uv segments generated for free with use of polywire SOP if you're generating them from curves. uvlayout SOP has an option to stack equal uv islands. if you're instancing, instances will have stacked uvs automatically (given they already have uvs done before instancing).

in the inline VOP you can define as many variables as you want. any variable can be exported if you specify matching name in Outputs section of inline VOP. you don't have to export all the variables defined in code thou. only if you want to send any particular variable further down the stream you have to export it (you always want to export at least one variable obviously). variables that are not exported only exist within the particular inline VOP.

yeah typically you can have a parameter Name and then Label which can be more user friendly or something. not sure thou where Label gets propagated with inline VOP. you can't export parameter that's not been defined. in other words, you can only export parameters that you are using in the particular inline VOP. that's the entire logic. on output, inline VOP is looking for the equally named existing parameter and if that doesn't exist it raises an error that parameter is unidentified or something along those lines.

there are no links or anything. it's paired by names. so if you want to export $pngLng your output has to be named the same, as well as data type. the right side column from the output variable name is supposed to be Label. Not sure how that can be used in this case...

well you should be able to figure out the layering with phantom and matte objects on your Mantra ROP... not sure what are you seeing so hard to give an advice. did you try to comp it together? was it looking wrong?

this should help

if you need to keep polycount low then maybe displacement map is a good solution for you. you can generate low poly mesh with uvs and then bake the hires geometry detail into the uv texture.

hi, regarding the method, for rendering/compositing volumes separately create two ROPs, one of which will render all volumes as phantom objects and the other one will render everything else as phantom object. so you'll end up with one render having only the building visible and the other one having only the volume visible. phantom objects are still casting shadows and affecting nearby surfaces so you should still see the volumes shadowing your building, etc. that should work well enough in this case. in comp you just put volumes on top of the building layer and you're done. for applying (or pretty much anything) do the best quality you can. if you see that some parts are grainy or not looking great, try to improve it if possible. your render looks quite good (render quality wise), only the beginning with colored particles seems to be pretty noisy (but hard to see due to compression). volumes at the end are a bit noisy too, and i'd render them cleaner if i could afford it, it's not a big deal thou. anyways, my opinion is that for getting a job you'll need more things to show than this... it's a good start thou. good luck.