Why don't you have the luxury? It would make no difference if Houdini was written in Julia. You'd still have all the same problems having the software running optimally on all the platforms. In fact Julia being so immature you'd have a vast number of far more mundane problems as well. Don't underestimate the difficulty of writing large software systems, in practice pushing the bounds of computation is insanely hard. Even with Julia on a Mac It's taken 27 years for Houdini to arrive at it's current sophistication. And the devs don't have a blind spot, it's your job to adapt the (incredibly flexible) tool to your use. Most current systems "pushing the bounds of computation" are developed in fortran and C/C++, sometimes scripted from python. I.e. just like Houdini and AI training. But I'd also note that pushing the bounds of computation is not the same thing as building complex DCC tools like Houdini.
PHENOMDESIGN
drew choose your hardware and OS to support your software
In my "Industry" we do not have that luxury. It is standard to use a literate programming language closer to the math and plain language such as Julia and compile to the specific platform.
The "Software" should handle this abstraction. Apple platforms performance is so students can learn, other researchers can on-board, and scientific systems can be crafted for immediate implementation using physics-based learning.
I think that there is a really big blind spot in understanding that Houdini is used in vital and mission critical systems design scenarios of which push the boundaries of computation. One application with the new rigging system is applied medical animation research.
" -- Interviewer asks -- " Is there any basis for comparing you to say Mattel and Atari, or is that like comparing Apples to Oranges? ""
" -- Steve Jobs -- " We describe our business as making tools not toys....other people are interested in an entertainment value, which is valuable of course too, but that is not our business. ""
I'm sorry but wouldn't it be reasonable to expect one of the largest and richest companies in the world to have rock solid support for industry standard graphics APIs? Consider bringing this up with your Apple representative. In the meantime choose your hardware and OS to support your software.
Really interested in this work, and timely as I'm currently trying to automate building a hqueue farm. In the past I've done it with cobbled together scripts and files shared via NFS mounts, but now that hqueue has python3 support it's time to modernise.
At the moment I get this error if I try and run houdini with your container. Hython and hscript work fine. I'm running on Ubuntu 22.04. (For my purposes I'll mostly be running headless tasks.)
root@539d5b0c2631:/opt/hfs19.5# houdini /opt/hfs19.5/bin/houdini-bin: error while loading shared libraries: libsmime3.so: cannot open shared object file: No such file or directory
liberalarts Sure. But could Houdini learn from other software? Yes. Could Houdini be more user friendly? Hell yes.
The other question to ask here is could Blender's UI be extended to provide the vastly more complex and deep functionality of Houdini and still be "user friendly"? I'm going to suggest the answer is no.
This fixed the problem for us, except we were having it with Ubuntu 20.04/h19 (h18.5 was working ok). Curious to know how/where you found this fix? I wasted quite a few hours reinstalling nVidia drivers and other futzing around.
Cheers Drew
kubo-von
mariusz8 In my case this fix is not working:
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Daryl Dunlap Well, with the Arnold 7 launch, it reminded me, that Houdini only has partial NanoVDB support, I wondered if SideFX improved NanoVDB support in H19?
NanoVDB is still being developed and hasn't made it into the main OpenVDB distribution yet so it's going to be hard for any application to expose it fully till that happens.
It could be as simple as the task being memory bandwidth limited, to the CPU and/or GPU. And for the GPUs in particular many tasks have components that are inherently scalar and hence can't take advantage of the parallelism of OpenCl. The more complicated the task the less likely it can be made to run efficiently on modern systems.
How does one go about developing a new scheduler type? At the moment if there is a problem with the python code the only feedback seems to be this error.
Load warnings for /home/drw900/HoudiniProjects/pbs/pbs_scheduler.hip Warning: Bad node type found: pdg_drw900_pbsscheduler in /tasks/topnet1.
Is there some way to see the python interpreter stdout/err, stack trace etc?
I have some quite large volumes (~40-120GB uncompressed) that I'd like to render and would appreciate any pointers to the current state of the art?
Before I go to the work of getting the data into OpenVDB format, I'm trying to find out if mantra (or any other production renderer) utilise out of core delayed loading of subsets of an OpenVDB volume? I note that the openvdb::File class supports delayed loading of volume chunks, but I don't know if this functionality is enabled and accessible from houdini/mantra.
After spending a few days investigating what was going on with H18 HQueue and submitting bug reports detailing how hqnode.ini files were being overwritten on startup, it's really frustrating to find out this has been moved into the web server. Why was this done? Why was nothing put into the configuration files mentioning the fact that they were now were being ignored. Nothing in the Whats New about HQueue changes.
I've spent a good deal of time building automated tools for:
- spinning up new linux VMs - rolling out new versions of HQueue, keeping versions and configurations up to date - installing hqnode clients that start on machine reboot, and restart on errors - running up the web server on boot, _not_ as the root user - creating a hquser on all the machines with the same uid/gid that allows a team to use HQueue without having the network mount completely open from a security standpoint - not requiring someone to put passwords in for every client they add, frankly it's scary that the web server wants to ssh into machines and do stuff behind my back, and doesn't scale to a large number of nodes
So the new changes just seem to be going in the opposite direction. It's obviously not testable at the moment as evidenced by the fact that it was completely broken on day one of the H18 release. Philosophically I just don't think that HQueue should be developed in this direction, it seems to me un-Houdini like. When administering multiple machines there are much better tools for system orchestration than buggy web servers holding user passwords. Configuration should be in one place, clearly documented, updateable, and automatable. At least give system admins a chance to do things the right way. Sorry for the rant but I had to get this off my chest!
BTW sometimes we have to nuke the server and database and start from scratch due to large render jobs being nearly impossible to delete. The server goes into 100% cpu and hours go by without a successful delete operation. I'm assuming that would mean putting the network shares back into the database by hand through the web GUI?
Maybe I'm expecting too much of HQueue? It's been a really useful, albeit fragile, tool that has rendered hundreds of thousands of frames for my small group over the years. We're hardware rich, but software poor so it has filled a gap when we couldn't afford Deadline, Tractor etc. But maybe now we should be focusing on developing a custom PDG scheduler for task distribution in our environment, something that I'm seriously considering?
It's taken 27 years for Houdini to arrive at it's current sophistication. And the devs don't have a blind spot, it's your job to adapt the (incredibly flexible) tool to your use. Most current systems "pushing the bounds of computation" are developed in fortran and C/C++, sometimes scripted from python. I.e. just like Houdini and AI training. But I'd also note that pushing the bounds of computation is not the same thing as building complex DCC tools like Houdini.
See here for a few examples of large weather simulations visualized.