The easiest way to get started is probably to use the hwebserver Python component of Houdini to run a web server. Here are some examples to get you started, depending on whether you'd like to render an image and display it or display 3D geometry in the viewport: https://www.sidefx.com/docs/houdini/hwebserver/fileResponse.html [www.sidefx.com]

goldleaf
I would keep it to Journal, unless it's the actual change log from the source tree

Internally, it's tightly linked to the source tree; we commit a file into a particular branch of Houdini and some automated systems assemble the log messages into a database and upload them to the web site.

It's definitely not as tightly linked to the source tree as our commit logs, but that would be too much information to sift through, hehe. Instead, it's a chronologically ordered list of notable changes for each build of Houdini, which is, well…, exactly how they describe a change log here: http://keepachangelog.com/ [keepachangelog.com]

graham
Journal seems more appropriate to me given that the information contained in it is not automatically generated and is generally a partial/incomplete list of changes. It's essentially kind of like a “highlights” list.

Agreed, definitely not automatically generated and only showing notable changes. …But again, that's exactly what a change log is.

graham
Or you know, make it an much more accurate and complete change log

Hehe, the intention of it is to be accurate and complete, so if we're missing important things then it's a failure on our part, regardless of whether we call it journal or change log.

Mostly, I'd like to remove one more, albeit small, barrier for new users coming to Houdini by avoiding terminology that's different only for the sake of being different. I slightly worry that those users may not even be seeing this forum post, though, so we may not capture their voice.

We're nearly ready to enable the journal on our new web site, and we're considering renaming it to a changelog (or perhaps change log) to use more conventional terminology. Before we do so we wanted to first check with the community. Would anyone be opposed to this? Note that the URLs will redirect automatically, so there is no need for concern there.

matsbt
Will there be a Journal RSS feed for 15.5?

The 15.5 Journal RSS feed is now available at: www.sidefx.com/journal/rss.php?version=15.5 In the short term this will redirect to archive.sidefx.com.

Yes, the free Houdini Apprentice still exists for non-commercial use, and will remain an excellent way to learn Houdini.

Houdini Indie is now released: http://www.sidefx.com/index.php?option=com_content&task=view&id=2853&Itemid=66 [sidefx.com]

Are you calling PY_PyString_FromString?

HOMextendLibrary is still supported, but it is much more cumbersome to use than inlinecpp. For example, getting the creation time with inlinecpp is very little code (untested code below):

>>> inlinecpp.extendClass(hou.Node, “cpp_node_methods”, function_sources=[“”“
… int creationTime(OP_Node *node)
… {
… return (int)node->getStat().getCreateTime();
… }”“”])
…
>>> import time
>>> time.ctime(hou.node(“/obj/geo1”).creationTime())
'Thu Apr 24 11:06:12 2014'


Libraries created with inlinecpp can be distributed to other machines, so those machines do not need to have to be able to compile the C++ code on demand. inlinecpp is also entirely written in Python, so you can inspect and modify it to better suit your needs, or suggest patches to us.

This error has been fixed in Houdini 12.5.500.

Ah – clearing the geometry from a Python SOP will clear the cooked geometry, regardless of whether or not it's frozen. I've updated the documentation to hopefully better explain how frozen geometry works:

freeze(self) -> hou.Geometry:
Return another Geometry object that is not linked to a particular SOP.

Normally, when you call , the resultant Geometry
object retains a reference to that SOP, and is said to be unfrozen. Each
time you access points, primitives, attributes, etc. in an unfrozen
Geometry object, Houdini uses the SOP's latest cooked geometry. So, if you
change parameters or change the time for an animated SOP, the Geometry
object will update to the SOP's new geometry.

Unless Python SOPs are involved, a frozen Geometry object does not have a
similar live association with a particular SOP. If you ask a SOP for its
geometry and then store a frozen copy of that geometry, when the SOP
recooks the frozen Geometry object will not update. Instead, the frozen
geometry saves its own copy of the point and primitive data, and is
unaffected by subsequent changes to the SOP. When a frozen Geometry object
is destroyed, any geometry copy it created is also destroyed.

Note that accessing a Geometry object's points, primitives, attributes,
etc. may be faster when dealing with frozen objects. You may want to work
with frozen Geometry in speed-sensitive operations.

Calling this method on an unfrozen Geometry object returns a frozen
one. Calling it on a frozen object has no effect, and it returns
a frozen object.

When a Python-defined SOP cooks and runs Python code that asks for the
SOP's geometry, the returned Geometry object is writable. Modifying this
Geometry object affects the output of this SOP. For efficiency, this
geometry object is already frozen, so calling freeze on it has no effect.

Ah. One way to do it is to access the globals dict where the function is defined using the __globals__ attribute of the function object:


from functools import wraps
import inspect
def foo(func):

print “wrap”

@wraps(func)
def with_logging(*args, **kwargs):
print func.__name__ + “ wrapped”
return func(*args, **kwargs)

print “wrapII”
if inspect.getmodule(func) is None:
func.__globals__ = with_logging
else:
setattr(inspect.getmodule(func), func.__name__, with_logging)
return with_logging


def toWrap(x):
print x + x * x




foo(toWrap)
toWrap(2)

I'm not sure I fully understand what you want to do. Do you want to make a function in a different module appear as though it's defined in the code inside type properties?

If so, one way accessing the current module's dictionary is via globals():
globals() = other_function

Of course, if you're already running this from outside a function/method, you could just write:
function_name = other_function
or
from other_module import other_function

Note that one of the benefits of pythonrc.py is that you can be sure it's automatically run exactly once (unlike 123.py, 456.py, etc.) So, I'm quite hesitant about running it from shelf tools automatically.

However, you should be able to run it explicitly from your shelf tool with: execfile(“pythonrc.py”).

If you're just using pythonrc.py to import modules, I'd recommend importing them manually into your shelf script. If pythonrc.py sets global variables, though, you can import __main__ from your shelf script and use it to access them.

Did you source houdini_setup before starting Python? The “unknown error” messages suggest that $HFS might not be set.

One easy way you can do this is to use the HOM C++ interface. It follows the Python interface fairly closely. (In fact, the Python interface is generated from the C++ interface.) So, where in Python you would write:

g = hou.node(“/obj”).createNode(“geo”)

you could also write, in C++:

#include <HOM/HOM_Module.h>
#include <HOM/HOM_Node.h>
#include <boost/shared_ptr.hpp>

HOM_Module &hou = HOM();

boost::shared_ptr<HOM_Node> g(hou.node(“/obj”)->createNode(“geo”));

The code above, however, has a memory leak; HOM_Module::node() returns a new HOM_Node instance. However, we can use the handy HOMdel() function to automatically delete the object for us. The example then becomes:

#include <HOM/HOM_Module.h>
#include <HOM/HOM_Node.h>
#include <boost/shared_ptr.hpp>

HOM_Module &hou = HOM();

boost::shared_ptr<HOM_Node> g(HOMdel(hou.node(“/obj”))->createNode(“geo”));

To do it from Python, you would write:
hou.node('/obj/geo1/null1').geometry().saveToFile(“file.bgeo”)

Note that Python event handlers are supported in later versions of 9.0. The node is available via kwargs. So it would be something like:

node = hou.node(kwargs)
node.hdaModule().main(node)

The only advantage is being able to hit escape, though that's a pretty big one. It's especially nice to not have the interrupt dialog keep popping up for each frame when you're simulating.

A bug in X has recently been fixed so we can now support the tablet when threaded UI is turned on. Later versions of Houdini will check the version of X to see if the fix is there.

Unfortunately, not all the bugs have been ironed out of threaded UI on Linux in Houdini 8, so your mileage may vary. Our goal is to have it stable for the next release, though.

There is no way I know of to do what you want with autoscoping. The only way I know of to scope just the parameters with channels is to bring up the Scope Channels Dialog… and press Scope.

The fix for this bug should be in tomorrow's 8.0.394.

We don't have any plans to add a standalone mode for Linux. Licensing should work properly on Linux with DHCP if you configure Linux to not change your host name whenever it connects via DHCP. Is that not the case for you Peter?