So... I've been going through Solaris related Mardini 2024 videos and Lighting Nodebook... I mean... I don't know what to say... stability is brutal... All I've really been doing is working with material linker, material library... super simple stuff. I get crashes, errors, sht not working... absolutely brutal (this is latest daily build).

For example, just added material linker:

Traceback (most recent call last):
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husdui\models\primtreemodel.py", line 798, in dropMimeData
handled = handler.dropMimeData(mimedata, action, row, column, parent_index, self.stage(), self._node)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\materiallinker\mlpanel.py", line 460, in dropMimeData
if len(assets) > 0:
^^^^^^
UnboundLocalError: cannot access local variable 'assets' where it is not associated with a value

I've never seen as many errors and instability in Houdini... The whole release feels like an early beta to me...

Another one... I mean literally just adjusting multiply values on a fking multiply shader... brutal... I have never seen this in any Houdini release... at least not for the last 10 years...


Traceback (most recent call last):
File "<stdin>", line 8, in <module>
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\shadertranslator.py", line 2561, in createMaterialShader
helper.createAndConnectUsdTerminalShader( shader_node,
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\mtlxshadertranslator.py", line 114, in createAndConnectUsdTerminalShader
output_path = HelperBase.createAndConnectUsdTerminalShader( self,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\shadertranslator.py", line 999, in createAndConnectUsdTerminalShader
return self.createAndConnectUsdTerminalShaderToMainOutput(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\shadertranslator.py", line 1056, in createAndConnectUsdTerminalShaderToMainOutput
usd_shader_output_path = self.createUsdTerminalShader(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\shadertranslator.py", line 1082, in createUsdTerminalShader
return self.createUsdShaderChain(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\shadertranslator.py", line 1196, in createUsdShaderChain
self.createAndConnectUsdInputShader( usd_shader,
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\shadertranslator.py", line 1285, in createAndConnectUsdInputShader
self.connectUsdShaderInputToUsdShaderOutput(
File "C:\PROGRA~1/SIDEEF~1/HOUDIN~1.326/houdini/python3.11libs\husd\shadertranslator.py", line 2103, in connectUsdShaderInputToUsdShaderOutput
UsdShade.ConnectableAPI.ConnectToSource( shader_input,
pxr.Tf.ErrorException:
Error in 'pxrInternal_v0_24__pxrReserved__::UsdShadeConnectableAPI::ConnectToSource' at line 170 in file C:\cygwin\home\prisms\builder-new\WeeklyDevToolsHEAD\dev_tools\src\usd\usd-24.03\USD-py3.11-qt5\pxr\usd\usdShade\connectableAPI.cpp : 'Failed connecting shading attribute </materials/GSG_TILES/mtlxsurface_unlit1.inputs:emission> to attribute on prim . The given source information is not valid'

At the moment I'm just trying to migrate an existing project to 20.5 and I'm getting tons of segmentation faults trying to sublayer or reference USD assets that were fine in 20.

Yes. A ton of segmentation faults here too.

Hey @LukeP, thanks for letting us know about these. Is there any chance you could provide a link to the specific files/videos from the Mardini challenge you were looking at? Or if these are your own entries, if you could submit them to support?

For segmentation faults, if you happen to get crash logs, please post them as well. If you're running on Windows you probably won't get useful crash logs so there's not much point in posting them, but Linux and MacOS they are usually very helpful. Either submit with bugs or just post them in this thread.

We obviously have people here who are doing these kinds of "simple things" all the time - putting down material libraries and material linkers. And we're not seeing these errors internally, so we need a little more help to reproduce them. Because if we can't reproduce them we can't fix them.

Anyway, I know you're frustrated, and you may be in the "everything I do crashes, and I've reported 40 bugs, and nobody is fixing any of them" camp. If so, I apologize. But we really aren't seeing anywhere near this level of problems (or we'd have fixed them by now). So any help you can provide we would really appreciate.

Hi guys. First of all - thank you for responding here. Just highlights how committed you guys are.

I’ve submitted a couple bugs requests specific to this. One of them being SESI #156162

Just got response today:
“Can you please rename your $HOME/Houdini20.5 folder to $HOME/Old_Houdini20.5 and restart the program? It doesn't look like your packages loaded properly so resetting your preferences by following this instruction might help.”

I’ll try this but honestly I’ve been doing this pretty much in weekly basis now. Most of the issues either can’t be reproduced or require me to wipe my home directory and still don’t fix things.

It’s nothing specific re tutorials. Was messing around with light mixer, material linker, material builder. Seems random. Typically you see some sort of UI malfunction or temp freeze for a second or so. Then errors like the ones in this tread. I’m on latest Win11 and latest nvidia drivers. Haven’t seen any of this instability in H20.

Thank you for your attention to this and for looking into it.

I'll add my personal addendum to Mark's note: screen recordings.

I know a lot of issues seem random and it's hard at the time to identify "what were the three key steps that led to this crash?".

I always get tremendous value in watching how users are interacting with the tools, when they're clicking on things that we really didn't expect them to (but of course are obvious in hindsight), etc.

If you can capture any errors/crashes during an active screen recording session, send it to us/me. Even if it's an hour long, don't crop the video just to the crash itself. If it means solving your issue, watching you innocently click around Houdini for an hour is a small investment on our part.

@robp - any screen recording software you’d recommend for this purpose?

I use simplescreenrecorder on Linux. Others use OBS on various platforms. It shouldn't really matter much.

LukeP
any screen recording software you’d recommend for this purpose?

There's plenty. Personally, I like to use FFmpeg [trac.ffmpeg.org]. I guess you can't get any simpler than that. Usually I just start a terminal with a hotkey and recall this line from zsh's Ctrl+R history:
Then I cut the video up and re-encode it to a smaller size in Avidemux [www.avidemux.org].

Peek [github.com] in WebM or MP4 modes, combined with FFmpeg or Avidemux to compress the video before uploading it wherever it needs to be uploaded, is also a nice option.

But, I guess most people use OBS, which is one of the GUI frontends for FFmpeg, plus a lot more. In fact my belief is that nowadays most of the screen recording software seem to be based on FFmpeg in one way or the other.

robp_sidefx
I'll add my personal addendum to Mark's note: screen recordings.

I know a lot of issues seem random and it's hard at the time to identify "what were the three key steps that led to this crash?".

I always get tremendous value in watching how users are interacting with the tools, when they're clicking on things that we really didn't expect them to (but of course are obvious in hindsight), etc.

If you can capture any errors/crashes during an active screen recording session, send it to us/me. Even if it's an hour long, don't crop the video just to the crash itself. If it means solving your issue, watching you innocently click around Houdini for an hour is a small investment on our part.

Expecting users to perform actions differently than what developers anticipate and causing critical issues is part of serious software development, isn’t it? The ability of developers to anticipate unexpected situations is a measure of the quality of the software being developed. What you’ve written could be used as an excuse by any developer of any program. You’ve been developing Houdini for many years now. Why was there no need to justify things this way 10 years ago? Perhaps the company has set a higher standard, and the developers are struggling with deadlines and insufficient product testing? Modern Houdini is far from the same as it was 10 years ago.

Regarding the bugs you report through the http://www.sidefx.com/index.php?option=com_content&task=view&id=768&Itemid=239 I’ve noticed an interesting feature: bugs are fixed selectively based on priorities. This is normal. However, it’s not normal when you report clear bugs and can’t even wait for them to be fixed in the next release. This is nonsense! So before praising the developers for reading and trying to address complaints, don’t forget those who reported bugs and still haven’t seen any resolution.

Alexey - does that mean that Modeller 2023 never had any bugs and Modeller 2024 will not have any?

LukeP
Alexey - does that mean that Modeller 2023 never had any bugs and Modeller 2024 will not have any?

Bugs are always present in any software. Check my chat to find out about bug fixes. And actually, I’m talking about Houdini, a program that has been developed for decades and by more than one person.

LukeP
Alexey - does that mean that Modeller 2023 never had any bugs and Modeller 2024 will not have any?

and key phrase: "Houdini is far from the same as it was 10 years ago."

Regarding the introduction of new features, I don’t understand them at all. Any user trying to switch to Houdini is quite surprised why such a serious DCC, which is excellent at handling geometry, lacks a simple feature like a proper way to display SubD geometry with isolines. Why is this feature, available in other programs for at least ten years, still missing here? Houdini uses OpenSubdiv but still hasn't this VERY important feature. Countless RFEs have been created about this, yet it somehow remains a low priority. Why is that? SideFX trying to "punish" Maya (I know this from correspondence with a Houdini representative). But Maya has had this feature since 2009 or even earlier. Is it not important for a VFX package? Houdini, even without isolines, displays subdivided geometry incorrectly. And nothing changes over the years. I repeat, countless RFEs have been created about this...

I agree that H20.5 and H20 have been unstable at the release. A balancing act between trying to be innovative and provide new awesome tools, satisfying our expectations for faster and bigger, and changing some core architectures (while maintaining both).

The software has gotten complex over time... Many more features have been introduced compared to 10 years ago. Hey, iOS was also less buggier 10 years ago.

I agree that there's quite a few very annoying things about Houdini that have been RFEs many times for years and never prioritized.
I agree that waiting across multiple releases for core bugs to be fixed is frustrating.

On the other side - this thread was really about Solaris instability that I have been experiencing. I think it's amazing for the Staff to take time to respond and be willing to look at screen recordings. I also don't think the world is as bad as Houdini is used in a sh*tload of movies. It is buggy though, constant viewport resets, etc. are very annoying according to a couple friends of mine who use Houdini professionally in VFX.

I do think that having a better way to record or intercept errors and bugs built into Houdini would be beneficial.
I mean more than half of my reported defects end up as 'sorry can't repro' or 'rename your Houdini home directory'... but ffs, I have been renaming it every few days now and it's still happening.

LukeP
On the other side - this thread was really about Solaris instability that I have been experiencing.

Yes, I wouldn’t want to write this in this thread, but I saw responses from developers here, so I couldn’t hold back. When I create threads about issues, I generally don’t get any responses. Maybe I touch on uncomfortable topics, or maybe they just find me unpleasant—who knows.

alexeyvanzhula1984

LukeP
On the other side - this thread was really about Solaris instability that I have been experiencing.

Yes, I wouldn’t want to write this in this thread, but I saw responses from developers here, so I couldn’t hold back. When I create threads about issues, I generally don’t get any responses. Maybe I touch on uncomfortable topics, or maybe they just find me unpleasant—who knows.

Or maybe it’s the delivery

LukeP

alexeyvanzhula1984

LukeP
On the other side - this thread was really about Solaris instability that I have been experiencing.

Yes, I wouldn’t want to write this in this thread, but I saw responses from developers here, so I couldn’t hold back. When I create threads about issues, I generally don’t get any responses. Maybe I touch on uncomfortable topics, or maybe they just find me unpleasant—who knows.

Or maybe it’s the delivery

What do you mean? I'm just talking about problems in Houdini. About very simple things.