kumpa

Thank you very much, that is exactly what i was looking for !

Is it possible to change default name of the operator when created ? I would like to shorten few of them, foreach_begin for example. cheers

Hi, I did, I had to enable write uv sets and uv write (not sure which one exactly made uvs appear in houdini) and when I noticed normals problem I tired no normals and that didn't work. No other option looksa like it has anything to do with normals but i'll keep trying nevertheless. The whole maya alembic - houdini workflow seems to be incredible convoluted, to my absolute astonishment I discovered that material assignments are not included in alembic file, so I had to export static fbx file, edit mental 10m long name attributes maya generates on both files until they matched and loop through all the objects to transfer names of materials from fbx to alembic.

Hi, I got some maya scenes I exported alembic caches from and it all went reasonably well until I had to make a pass with mantra cartoon shader ( the rest of passes are rendered with redshift) when I noticed normals on some objects are flipped, most of them in a manner typical to that of objects being mirrored during modeling with transformations frozen without normals being flipped. Going back to maya I also noticed that according to maya all the normals are pointing in right direction. Any thoughts on how to address that issue ? Maya being the mess it is and me not touching it for 10 years except as glorified file converter I can't seem to be able to debug the situation. Any help would be appreciated. Cheers

Main difference in my opinion is vastly reduced set of vops compared to mantra and very rudimentary volume shader. Other than that it is a lot like mantra except it is great deal faster. It is very prone to crashing if you don't turn off IPR while making changes to geometry while just tweaking shaders is fine. Regarding the amount of geometry/textures you can throw pretty much anything at it and it will render just fine. I recently finished project with loads of heavy meshes made from nurbs models and around 50 materials from megascans (mostly 8k) I thought I will downscale at some point but never actually had a need to.

Interesting. I did notice some odd artefacts in houdini and slack (!) but games seem to work just fine. Card is gf 1060 and I haven't meddled with it in any way. Thank you for the tip

Hey, sorry for late reply. Unfortunately I didn't, since it is my home computer I didn't bother too much. All I do is to apply all the updates to the system and hope for the best. I have no issues with it at work (Fedora 26). I am by no means a linux expert but I somewhat suspect latest nvidia driver to be the culprit ( 410.73 ).

Houdini 17 (both production and daily build) crashes upon opening preferences dialogue. Oddly enough, opening fairly complex scene doesn't seem to cause it to crash. This is what it says when it starts: k  /  opt  hfs17.0.396  X server found. dri2 connection failed! DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument Assuming 131072kB available aperture size. May lead to reduced performance or incorrect rendering. get chip id failed: -1 [22] param: 4, val: 0 X server found. dri2 connection failed! DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument Assuming 131072kB available aperture size. May lead to reduced performance or incorrect rendering. get chip id failed: -1 [22] param: 4, val: 0 cl_get_gt_device(): error, unknown device: 0 And this is what is says when it crashes: 3737: Fatal error: Segmentation fault (sent by pid 171) Crash log saved to /tmp/houdini_temp/crash.untitled.k_3737_log.txt And this are the contents of the log: Traceback from 3737 ThreadId=0x7ff31c34bd00 AP_Interface::coreDumpChaser(UTsignalHandlerArg) <libHoudiniUI.so> AP_Interface::si_CrashHandler::chaser(UTsignalHandlerArg) <libHoudiniUI.so> signalCallback(UTsignalHandlerArg) <libHoudiniUT.so> UT_Signal::UT_ComboSignalHandler::operator()(int, siginfo_t*, void*) const <libHoudiniUT.so> UT_Signal::processSignal(int, siginfo_t*, void*) <libHoudiniUT.so> __funlockfile <libpthread.so.0> PyDict_GetItem (dictobject.c:714) _PyType_Lookup (typeobject.c:2521) _PyObject_GenericGetAttrWithDict (object.c:1389) PyEval_EvalFrameEx (ceval.c:2256) PyEval_EvalFrameEx (ceval.c:4107) gen_iternext (genobject.c:84) PyEval_EvalFrameEx (ceval.c:2497) gen_iternext (genobject.c:84) PyEval_EvalFrameEx (ceval.c:2497) PyEval_EvalCodeEx (ceval.c:3253) function_call (funcobject.c:526) PyObject_Call (abstract.c:2529) instancemethod_call (classobject.c:2602) PyObject_Call (abstract.c:2529) call_method.constprop.47 (typeobject.c:1261) PyEval_EvalFrameEx (ceval.c:1391) PyEval_EvalFrameEx (ceval.c:4107) PyEval_EvalFrameEx (ceval.c:4107) PyEval_EvalCodeEx (ceval.c:3253) PyEval_EvalFrameEx (ceval.c:4117) PyEval_EvalCodeEx (ceval.c:3253) PyEval_EvalFrameEx (ceval.c:4117) PyEval_EvalCodeEx (ceval.c:3253) PyEval_EvalFrameEx (ceval.c:4117) PyEval_EvalCodeEx (ceval.c:3253) PyEval_EvalFrameEx (ceval.c:4117) PyEval_EvalCodeEx (ceval.c:3253) PyEval_EvalFrameEx (ceval.c:4117) gen_iternext (genobject.c:84) PyEval_EvalFrameEx (ceval.c:2497) gen_iternext (genobject.c:84) PyEval_EvalFrameEx (ceval.c:2497) PyEval_EvalCodeEx (ceval.c:3253) function_call (funcobject.c:526) PyObject_Call (abstract.c:2529) PyEval_EvalFrameEx (ceval.c:4334) PyEval_EvalCodeEx (ceval.c:3253) PyEval_EvalFrameEx (ceval.c:4117) PyEval_EvalFrameEx (ceval.c:4107) PyEval_EvalCodeEx (ceval.c:3253) PyEval_EvalCode (ceval.c:667) PY_CompiledCode::evaluateUsingDicts(PY_Result::Type, void*, void*, PY_Result&) const <libHoudiniUT.so> PY_CompiledCode::evaluate(PY_Result::Type, PY_Result&) const <libHoudiniUT.so> PYrunPythonExpression(char const*, PY_Result::Type, PY_EvaluationContext*) <libHoudiniUT.so> PYrunPythonExpressionAndExpectNoErrors(char const*, PY_Result::Type, char const*, PY_EvaluationContext*) <libHoudiniUT.so> PYrunPythonExpressionOfExactType(char const*, PY_Result::Type, PY_Result&, char const*, char const*, PY_EvaluationContext*) <libHoudiniUT.so> BR_HelpManager::runPythonExpr(char const*, PY_Result::Type, PY_Result&) <libHoudiniUI.so> BR_HelpManager::evalPythonExpr(char const*, UT_String&) <libHoudiniUI.so> BR_HelpManager::getHelpCardURL(char const*, UT_String&) <libHoudiniUI.so> FUSE_PrefDialog::handlePageChange(UI_Event*) <libHoudiniAPPS3.so> UI_Queue::processNextEvent() <libHoudiniUI.so> UI_Queue::drain() <libHoudiniUI.so> UI_Queue::eventLoop() <libHoudiniUI.so> main <libHoudiniUI.so> __libc_start_main <libc.so.6> main <houdinifx-bin> Fedora Core 29 NVIDIA Driver Version: 410.73 Anyone experiencing same issue ?

That's what I was thinking about. It was more of a curiosity than an actual issue anyway. Cheers

Is there a way to tell mantra to always render one shader in front on the other when rendering co-planar surfaces ? Cheers

I might be wrong but as far as i know nothing comes close to splashtop in terms of speed and portability

Thanks a lot , that is exactly what I was looking for

I am trying to create an attrubute that would tell me whether point on the curve turns left or right, say 0 for left turn 1 for right. Any ideas ? cheers k

I used to use cinnamon after gnome disaster on ubuntu, looked great but crashed too often for my liking so I switched to i3 and will never go back to silly floating windows ever again. Needs a bit of reading through docs before you can use it effectively but it is totally worth it. Also 12.5 viewport seems to be less of an issue.

I am having following problem: I am trying to extract one line from text file using `system("sed '$F!d' /home/kumpa/test.txt")` and it works fine. As soon as I replace $F with expression (stamp() in my case) it returns bracing error. Any ideas ? cheers k