The UTS Data Arena (Sydney Australia) has used Houdini for Data Viz since it opened in 2015.

Here's one example - the visualisation of bacteria. Images from a microscope (one per second)
were recorded and processed (Matlab) to locate and track bacteria, to better understand how
they travel (is it Stigmergy?) and communicate.

https://dataarena.net/projects/bacteria-life-sciences [dataarena.net]

There's more on the site. The Sydney Water pipe point-cloud was also processed in Houdini.

https://dataarena.net/projects/sydney-water-pipe [dataarena.net]

cheers,
ben.

fxrod
I got a reply from Side FX that works. Seems like my licenses list was pretty backlogged and was confusing the server. All I had to do was delete the licenses.local file under /Library/Preferences/sesi (please do not confuse this with path with /users/username/Library).

Installing the license then worked! Thanks, Silvina.

Yes, I just had the same problem. I'd install a new apprentice license and it
would already appear used (hkey shows 0/1 available).
Running Houdini would just go in circles with an offer to install another
apprentice license. Fail. There were a lot of old licenses, for sure.

It might be the OSX hostname changed. it now seems to be blah.local.local

Renaming “/Library/Preferences/sesi/licenses.local” to
“/Library/Preferences/sesi/licenses.local.19Aug14” & restarting sesinetd fixed it.
At first hkey is unhappy. Running HoudiniFX and choosing to install another
apprentice license creates a new license.local file. Then you're good to go.
Certainly, the new long SERVER code in the new license file is different..
hope that helps.

Hi,

Houdini running in: Gentoo Linux: 3.10.25-gentoo x86_64

I've recently seen something similar in Houdini 13.0.314

• $ houdini
  Warning: program compiled against libxml 209 using older 208
  Warning: program compiled against libxml 209 using older 208
  and with Houdini 12.5.483
  $ houdini
  ./hbrowser-bin: /opt/hfs12.5.483/python/lib/libz.so.1: version `ZLIB_1.2.3.4' not found (required by /usr/lib/libpng16.so.16)
  Warning: program compiled against libxml 209 using older 207
  Warning: program compiled against libxml 209 using older 207
  Warning: program compiled against libxml 209 using older 207
  ./hbrowser-bin: /opt/hfs12.5.483/python/lib/libz.so.1: version `ZLIB_1.2.3.4' not found (required by /usr/lib/libpng16.so.16)
  Gentoo is linux built from source.
  libxml has been compiled with the following flags:
  # emerge -pv libxml2
  
  These are the packages that would be merged, in order:
  
  Calculating dependencies… done!
  dev-libs/libxml2-2.9.1-r1:2 USE=“icu ipv6 python readline -debug -examples -lzma -static-libs {-test}” PYTHON_TARGETS=“python2_7 python3_3 -python2_6 -python3_2” 0 kB
  This gentoo “emerge” command indicates libxml2 (version 2-2.9.1) has been compiled for python targets 2.7 and 3.3 (and not 2.6 or 3.2)
  
  Following a post by Neil78 http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=29185&highlight=libxml [sidefx.com] referencing a Wolfwood post I tried setting houdini environment vars:
  $ export HOUDINI_PYTHON_BIN=/opt/hfs13.0.314/python/bin/python2.7
  $ export HOUDINI_PYTHON_LIB=/opt/hfs13.0.314/python/lib/libpython2.7.so
  $ houdini
  $ Warning: program compiled against libxml 209 using older 208
  Warning: program compiled against libxml 209 using older 208
  Warning: program compiled against libxml 209 using older 208
  still there. Same is true if HOUDINI_PYTHON var's are set to python2.6
  
  Checking what libxml is installed with houdini:
  $ cd /opt/hfs13.0.314
  $ find . -iname ‘*libxml*’
  ./python/lib/libxml2.so.2.8.0
  ./python/lib/libxml2.so.2
  ./python/lib/libxml2.so
  ./dsolib/libxml2.so.2.8.0
  ./dsolib/libxml2.so.2
  ./dsolib/libcollada_LIBXMLPlugin.so
  ./dsolib/libxml2.so
  ./mozilla/components/libxmlextras.so
  ./toolkit/include/libxml
  ./houdini/help/licenses/libxml2.html
  ./houdini/help/licenses/libxml2.txt
  ./hsvg/libxml2.so.2.8.0
  ./hsvg/libxml2.so.2
  ./hsvg/libxml2.so
  It looks like the libxml shipped with Houdini 13.0.314 is “208” not “209” (?)
  
  b.

Here's a thought - are you trying this sort of approach?

% hexpand thing.hip
% grep -ir stiffness thing.hip.dir

that will show you all the op's which have the stiffness expression…

If there aren't many, you could txt edit them, then “hcollapse” to get your new hipfile.

% hcollapse thing.hip.dir

tadah.

What follows here may void your hipfile warranty. - Feeling braver? You could send that list from grep to a list-of-files with ‘-n’ and build a “sed” shell script on the results. The sed can do a search & replace (which is fine if all you need to do a simple string translation). eg.

% grep -irl stiffness thing.hip.dir > files.txt

files.txt will have the filenames of each file which contains ‘stiffness’. Now edit it to look like this:

% sed -i old.def -e ‘s/sedgestretchstiffness/shellstretchstiffness/’ thing.hip.dir/obj/clothness/somehardnesspoly.def

the ‘-i old.def’ should rename the orig file to be ‘blah.old.def’, so it will appear in the hipfile when you hcollapse it all back together again. Mileage may vary..

For bonus points, you could wrap all this up into a find(1) command, where the sed is done in an -exec flag, but that'd be too tricky to maintainable! :-)

The hexpand and grep might be practically useful tho' - just to know where they all are, and a final check to be sure you've got them all.

It's hard to know what you want to do, but here's an line of thought: you can create lots of additional point attributes attached to each point with an ATTRIBUTE CREATE SOP. This might lead you down the right track for what you want to do.

For example, to start, you could make a new point attribute called ‘origPt’ and copy the point number values to this new attribute. Now you have the point numbers, and the original point numbers. If you do a sort, the point numbers will change, but the ‘origPt’ attributes do not. They stay unchanged.

Now, you could have attributes which represent the “point numbers” for sorting along each axis. The Sort Sop will only change the ‘built-in’ point numbers attribute, but there's many SOPS which address user-added attributes. Hit Tab in SOP's Network and look in the Attributes Menu. Add as many new point attributes as you like, for a view along each axis, etc.. HTH. b.

here's a quick guess.

Run “HKey” (the Houdini License Admin Tool) and take a careful look at the output from View->Diagnostic Information option. Does it say you are using the locally embedded license validator, or hserver/sesinetd? You might need to change it to be local. Depending on which Operating System you're using, this can be changed manually by editing a txtfile (via Houdini Shell) called

$HFS/houdini/Licensing.opt

If you have:

licensingMode = sesinetd

try commenting-it-out & changing it to:

# licensingMode = sesinetd
licensingMode = localValidator

not sure this will solve the issue; it's just a suggestion.
be prepared to undo this mod!

cheers,
ben.

+1

Hey tjeeds. yep. i'm seeing the same thing on a new linux installation.
Did a ‘search’ and found your post.

Linux Houdini-FX Apprentice 12.5.427 (linux-i686-gcc4.4)
Linux is 3.8.13-gentoo SMP i686 Intel(R)
Help window shows one line of text: "http://localhost:48626 [localhost]“

Help from the ”File Menu" works though (?) - Help->Start Here pops up a Konqueror Window with the help in it.

Also got a crash:

Crash report from ben; Houdini FX Version 12.5.427
Traceback from Tue Jul 23 11:58:59 2013
Caught signal 11
AP_Interface::coredumpHandler(UTsignalHandlerArg) <libHoudiniUI.so>
UT_Signal::processSignal(int, siginfo*, void*) <libHoudiniUT.so>
<linux-gate.so.1>
FUSE_Office::getHelpBrowser() <libHoudiniAPPS3.so>
FUSE_Office::getHelpBrowser() <libHoudiniAPPS3.so>
FUSE_App::getHelpBrowser(float, float, bool) <libHoudiniAPPS3.so>
FUSE_HelpManager:penURLInWebBrowser(char const*) <libHoudiniAPPS3.so>
BR_HelpManager:penHelpPath(char const*) <libHoudiniUI.so>
BR_HelpManager:penHelpCard(OP_Operator*) <libHoudiniUI.so>
BR_HelpManager:penHelpCard(OP_Node*) <libHoudiniUI.so>
OPUI_MainApp::showOperatorHelp(OP_Node&) <libHoudiniAPPS2.so>
OPUI_Dialog::handleClickHelp(UI_Event*) <libHoudiniAPPS2.so>
UI_Queue::processNextEvent() <libHoudiniUI.so>
UI_Queue::drain() <libHoudiniUI.so>
UI_Queue::eventLoop() <libHoudiniUI.so>
main_part2(int, char**) <libHoudiniUI.so>
main <libHoudiniUI.so>
__libc_start_main <libc.so.6>
_start <houdini-bin>

Lin64, H11.0.504

I'm looking into a way to document OTL's on a stand-alone doc server. The stand-alone doc server is up and running.

At the moment, the help sections within OTL's is not being served, nor indexed. Is there some special way to extract the help from OTL's? Do we need to write a script? (eg extract each help “section” to a txt-file, and put them in a dir which is referred to in the “docs =” line of the deploy.ini file)?

A simple test worked: a “custom” helpfile, put it in a dir on the “docs=” line was indexed and served.

Is the original (2008) comment about @nodes not working still true? Because it appears that @path works. Though, @shelf does not.

thx, ben.

PS. Also, I've begun to wonder if the deploy.ini file is fully-correct? I notice changing the “port =” setting in the deploy.ini file does not work (found in the "" section of the deploy.ini file). However, the actual call to exec serve() method in serverCopy.py can be given a port number, and that works.

eg. change the line:
serve(app, None, start_loop = True)
to
serve(app, port=8088, start_loop = True)

@rafal - there's already an RFE? OK thanks!

@JC yes, sometimes users just start hscript or hython in a shell, plus we have written (HDK) bgeo conversion tools which take a license. We're looking at open source ways to handle bgeo, as a partial work-around.

imho the work-arounds with wrappers and “test jobs” aren't production solutions.
1) There are over 200 binaries in $HFS/bin - would we wrap them all, for each release?
2) user workstations are on the farm, so hserver can't be restricted to gui or non-gui.

I'd imagine tickets would be new and optional - even for redundant servers. ie: Sesinetd could still issue licenses without tickets. What's new is a license can be issued to a ticket instead of a hostname. Then, a renderhost asks to swap the ticket for its hostname. Oh, the other new thing is licenses with old/untaken tickets get released.

Executive Summary: Sorry Sir, That Table is Gone.

I wish this RFE & discussion was still on-line. This issue has come up again, now at Dr D.

Is it not equivalent of obtaining a return code that indicates there is no licenses?

They're not equivalent, because there is a “Race Condition”, solved by a reservation. The problem occurs when there's a return code saying there is a license available. You can't trust this, because if you then go start a job someone else might take the license while the job is being dispatched!

Perhaps we are not envisioning the same mechanics of the rendering supervision system.

Indeed. It's no good to think there is a license available, dispatch a job, and then have it fail because the license was taken by a user on a workstation. That's a waste of time and resources. In the current scenario, we don't see the failure until the end of the job, the next day, or until a Wrangler spots it.

… the render node could store the render data for the failed job

Oh no thanks. Leaving the job dispatched and have the render-blade then poll/plead for a license just makes the race condition worse. The farm will become locked up, idle, waiting and hammering the License Server.

I think the original post outlined the protocol request (in 2007). Essentially:

1. The Job Dispatcher asks for a license type, and specifies a time-out (say 5 minutes)
2. If there is a license available, the Houdini License server replies yes, issues a ticket-number, and holds the license as “reserved” for that time-out period.
3. The job dispatcher then sends the job to the render-blade with the ticket number
4. The render-blade starts the job, and takes the license by sending the ticket number to the License Server.

It's like reserving a table at a restaurant. I don't want to phone up a place asking if there's a table free, only to drive downtown and find out someone else took it.

cheers,
ben.

Hi,

Houdini 11.0.454, Linux x86_64 2.6.18-164.el5

A couple of guys here were messing around with an OTL which breaks when it's inside another OTL. Kind of strange. I've made a little demo / test-case. Making the inner OTL “editable” via the Type Properties didn't help. I was going to post this to the v11 beta forum, but it looks like that's closed now. It's probably worth SESI taking a look at what's happening.

The unusual thing going on here is the inner OTL has parms which cross-reference one another. That is, when you update one parm, there's a call-back which updates the other. This is done via an opparm() in the inner OTL. To demo this, i've made a simple “crate” with 2 parms on it; scale and position. Moving one changes the other.

When this crate is put into another OTL, named superCrate, this update/call-back breaks in various ways, depending on what you do to try to make it work! Generally i've seen one of the parms on the inner OTL gets blown-away. Eg change the superCrates OTL parm “crate1 a Translate Y” parm from 0.5, and the parm inside on crate1“a Scale Y” (being ch(“../crate1_asy”) ) gets cleared! Other times when it's all locked-up the update of the other parm (on the inner OTL) doesn't happen.

There's a hipfile and otl attached, which i made in /tmp/sc

cheers,
ben.

ha hah hah hah ha!


oh? too late on the joke?

PS. I'ze doing a Search for “freeze dop” and this was the only thead…

probbins
Anyways, attempting the callback using a Button to run a unix command. However the callback is set to use csh commands and I'm using bash (ubuntu)

Hey Pete,

csh or bash shouldn't matter because either will run “mencoder” okay.

Start to build the command up, eg. first of all place a button type in your OTL with the callback being: unix date
Click on the button and you should see the date in the shell where you ran houdini. See that that works first.

adding in use of hscript's “message” is always helpful for callbacks too.

Change the callback now to: message `system(“date”)`

And now, how about this: set cmd=“date”; message `system($cmd)`

From there, it's a matter of changing ‘date’ to be ‘mencoder’ with all the
required mencoder command args, etc. Once it's working, you'd probably
want to change the message to something else, possibly with an option to
cancel/confirm the operation. yada yada. If you have the filenames in
another (invisible?) parm of the OTL you can refer to those via chs().
i hope that's not too cryptic.

Another way to approach this is to write a simple shell script which does
much of what you need to call mencoder - that way you can cut down the
number of args to be passed out from Houdini, and do all the string munging
of filenames etc in the shell script (or a python script!) which in turn calls
mencoder. That reduces the complexity inside your OTL, and eases
future maintenance (because you'll most likely only need to update the shell script).

cheers,
ben.

What DOP Technical Evening? In Toronto?

Hi,

The resample sop appears to resample a line by vertex order, not point order.
If you reverse-sort the point numbers on a line, the resampling direction
is not reversed.

I think it would be useful if the resample sop had an option when using
“Maximum Segment Length” and “Maintain Last Vertex” where you could
ask that the resampling is done in reverse vertex order.

When resampling a line with a fixed segment length, there's usually a little
bit left over - at the end of the line (at the last vertex). There's an option to
clip this off, or include it (“Maintain Last Vertex”).

In a sense, this RFE would mean the “First vertex” would be maintained,
and the smaller/remaining segment would be at the beginning of the line,
between points 0 and 1.

is this crazy talk?

b.

Hi jimbob8s,

It really helps to be looking carefully at the “Details View” pane (hit Alt+4
to get this pane). The names in the left hand column are what you're
looking for. Alternately, if you're just “hacking” you can use an integer to
refer to each object (feeling lucky?).

This example was typed into the Houdini textport.
That is, instead of using the name in a dopfield expression, say:

-> echo `dopfield(“/obj/floor/dopnet”, “plank_0”, “Position”, “Options”, 0, “py”)`
-0.0099743

You might know your object ($OBJID) is number 3 (!) and so:

-> echo `dopfield(“/obj/floor/dopnet”, 3, “Position”, “Options”, 0, “py”)`
-0.0099743

But this is hackery alright.

I'm guessing that you haven't created group names for all your fractured
geom. This is done by appending a CONNECTIVITY SOP followed by a
PARTITION SOP to the sop-chain going into Dops. eg. Set “primitive” on
connectivity, and set Rule: CL_$CLASS on the Partition Sop.
MMB on the Partitiion SOP and you should see groups: CL_0, CL_1 etc.
I think there are some DOP's help examples which demo this.

With the RBD Fractured Obj DOP the group names become the dop object
names. That's how I get: plank_0, plank_1, etc etc. These groups can be
used on the output side of Dops.

If you get really stuck, you can also try building up the name by knowing
that the Connectivity Sop created a Primative Attribute (eg. “class”) which
you could get again via a prim() expression. eg:
“plank_`prim('../input_to_this_op', $PR, ‘class’, 0)`” where “input_to_this_op”
is a null sop parented to whatever sop you're using this expression in.
it's a bit crazy, but it works.

cheers,
ben.

Hey Wolfwood,

if ya need a shirt - here's one!

Also, take a look at the “Edges” option in the parameters for the Group Sop.
(UnEnable Number, Select Edges, then Enable it, then enable Edge Angle)

It adds prim's to the group if the angle between 2 surfaces along an edge
is above a certain threshold. Once you make a group you can do things to it…
Not quite what you want, but it might help.

cheers,
b.

Heya,

I just reviewed what's going on with tar and sesinetd.install (H8.1.934)

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=6321&highlight=tar+wildcards [sidefx.com]

edward
I think you need to add –wildcards to the tar command line as noted on this thread:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=6304 [sidefx.com]

My personal take on it is that the latest tar is broken and users should log bugs against it. Notice that there are no wildcards given in the first place in those scripts.

Heh. Good luck with lobbying GNU to change tar! Let me know how that goes.. I doubt any change will happen.

Nb: http://www.gnu.org/software/tar/manual/html_node/Changes.html [gnu.org]

GNU tar: an archiver tool

This manual is for GNU tar (version 1.16.1, 7 December 2006), which creates and extracts files from archives.

Appendix A Changes

This appendix lists some important user-visible changes between version GNU tar 1.16.1 and previous versions. An up-to-date version of this document is available at the GNU tar documentation page.

Use of globbing patterns when listing and extracting.
Previous versions of GNU tar assumed shell-style globbing when extracting from or listing an archive. For example:

$ tar xf foo.tar ‘*.c’

would extract all files whose names end in ?.c?. This behavior was not documented and was incompatible with traditional tar implementations. Therefore, starting from version 1.15.91, GNU tar no longer uses globbing by default. For example, the above invocation is now interpreted as a request to extract from the archive the file named *.c.

To facilitate transition to the new behavior for those users who got used to the previous incorrect one, tar will print a warning if it finds out that a requested member was not found in the archive and its name looks like a globbing pattern. For example:

$ tar xf foo.tar ‘*.c’
tar: Pattern matching characters used in file names. Please,
tar: use –wildcards to enable pattern matching, or –no-wildcards to
tar: suppress this warning.
tar: *.c: Not found in archive
tar: Error exit delayed from previous errors


To treat member names as globbing patterns, use ?wildcards option. If you want to tar to mimic the behavior of versions prior to 1.15.91, add this option to your TAR_OPTIONS variable.

See wildcards, for the detailed discussion of the use of globbing patterns by GNU tar.

Meantime, sesinetd.install is broken. It fails to install for tar version 1.16+

I think it might be more effective to embrace the change, and modify
the sesinetd.install script, which uses the wildcard character “*” at line 206
(eg. in houdini-8.1.934-linux_rhEL4.tar.gz). The line is:
gunzip -c $HERE/houdini.tar.gz | tar xf - “houdini/sbin/sesi*”

SESI - Here's a /bin/sh code snippet which would handle this situation:


#!/bin/sh
#
# An example script which decides whether to use the tar –wildcards option
#

#
# Put the gnu tar version numbers into a bash array
# We process a line which looks like this: tar (GNU tar) 1.16
#
declare -a tar_vers='( ‘`/bin/tar –version|head -1|awk ’{print $NF}'|sed -e ‘s/\./ /g’`' )'
tar_major_version=${tar_vers}
tar_minor_version=${tar_vers}


#
# Set the tar wildcards argument
#
if []; then
WILDCARDS_OPT=“”
else
echo tar will use the –wildcards option
WILDCARDS_OPT=“–wildcards”
fi

#
# call tar, assume $HERE is set
#
## /bin/tar zx $WILDCARDS_OPT -f $HERE/houdini.tar.gz ‘houdini/sbin/sesi*’
echo /bin/tar zx $WILDCARDS_OPT -f $HERE/houdini.tar.gz ‘houdini/sbin/sesi*’

The tar line assumes $HERE is set (it's set in sesinetd.install), and it uses
the ‘z’ option to ‘gunzip’ the archive. It only checks for versions <1.16,
a third subversion test (${tar_vers) could be added to improve the test.

cheers,
ben.