Thanks to Support I've learned that there's an issue with current nvidia drivers, try going back to 416.34.0.0, that has worked for me!

This is still broken with 16.5.405. I mean, seriously?

Afaik it's for those who wrote C++/Python plugins that rely on version 4 of Qt.

I've been playing with GLSL shaders but so far I haven't worked out how to access things like point scale. Are there any samples around somewhere?

Hey guys,

I've just experienced the strangest (and nastiest) but just now in 15.607. Unfortunately I can't reproduce it after rebooting, but I was wondering whether anyone else hit it too.

Basically what happens is that at some point during save, Houdini wipes all and every custom parameters from the nodes. Every single one. They are all reset to default. I'm using Octane, not sure if that is related or not (all those parameters were gone too).

Luckily I had an earlier backup which was fine, but that was again corrupted later (until I now rebooted and everything is fine again).

Since I cant reproduce it now, there's not a lot I could put into a bug report, but maybe you have seen something like this happen as well?

Michael

Have you by chance heard back from Sidefx regarding whether they plan to incorporate it? This would be very, very cool. I mean, in-app access to its C++ SDK? That's be a first I think, and it's just super powerful.

Heyho,

I've just started a github repo where I'll be putting my public scripts in the future. For now, it's just a simple incremental save script. I like having control over when I increment my versioning and how it's formatted, so that's why I wrote this simple shelf tool. Feel free to play around with it…

https://github.com/flipswitchingmonkey/fsm_vexnstuff/tree/master/shelf [github.com]

Cheers
Michael

15.5.560 works (and the latest 523 octane build works with that one too, of you use that)

15.5.560 (daily build) seems to work again

I've posted this as a bug (since I'm experiencing the exact same issue now), let's hope there's a quick solution.

You can use OBJ, Alembic or FBX for example. All of those should work fine between C4D and Houdini.

Has anyone else had this issue? It's only happening on my machine with the latest nvidia drivers and an original Titan. On a different machine OpenGl renders fine.

Basically what it does is render bright blue dots for every vertex, regardless of any setting I set up.

Yeah, no, what I meant was to create for example instead of “stop” another attribute called “stop_nexttime” and then check that one and if that is set, set “stop”. Yeah, it's convoluted, but that'd work I guess.

Yup, seems like the stop condition is evaluated first. So I'd probably just do something like if(detail(“attribwrangle2”, “stop”,0)==2, 1, 0) and raise the stop attribute twice. Hardly elegant, but probably the only way (or make your test inside the foreach so that it only sets “stop” _after_ it ran successfully)

Hi Admir,

if you import the alembic as polygons the particles are imported as disconnected vertices without any of their attributes, which is fine if they are to be used for a cloner for example, but otherwise you need to import them as particles geometry. Note that they come in as Thinking Particles particles, not as “regular” cinema particles.

Now here's the kicker: in theory, you would now be able to access the attributes through TP Data Channels. However, due to a bug in how Alembic is implemented in C4D, currently Cinema does expect the attributes to be on the root level of the Alembic file when in fact they are all located beneath “arbGeomParams” (where they belong). And as far as I know, right now there is no way to get to them with standard c4d tools.

You can however overwrite the Size or Scale parameter in via TP in Xpresso and that is easily done. If you don't need the original attributes from Houdini and just want to scale the particles in Cinema, import them as Particle Geometry and run them through a simple Xpresso setup

Thanks, that makes sense
(though it'd probably be good if the naming on the gravity node would be slightly different than on the other force nodes, since calling it all “Force” is pretty confusing tbh.)

I'm curious if someone could give me a hint as to how external forces are calculated where FEM solid objects are concerned.

Take a simple solid object. By default a Gravity DOP will be attached, adding to the downward force. This will work as expected.

Now replace the Gravity DOP with an Uniform Force DOP or any other node that modifies force. Notice how they barely influence the object at all. To get a behaviour similar to the Gravity DOP you need to input forces of -1000 or more!

Why is Gravity “special” here?
Is there a drag parameter that is set so high by default that other forces are almost ignored, and if so, where is it hidden?

Cheers
Michael

It'd be awesome if we had access to the hou.session module from within VEX and if we could store data in there as well. That'd solve so many problems…

Yeah, they don't. But it's trivial to add (Allow Editing > add Bind/Parameter node and connect to computelighting1 ‘Of’ input, done), so I don't quite understand why it wasn't done. And it is definitely useful to have, imho.

Is it possible to somehow disable the interpolation that takes place when the width or pscale attribute on a point changes between points? E.g, when it changes from 1.0 to 0.0, to receive a hard edge as an output (similar to how ramp parameters behave when turning the interpolation to “constant”.

For example, what I want in the attached example is for the rendering to appear as “on/off” instead of the pinched endings. Those pinches are some sort of interpolation between the 1.0 and 0.0 width points. Same happenes with the curve render and rendered as a polywire.

(I know I could create multiple “sliced” nurbs curves, but I'd prefer to use a ramp to adjust the widths for a full curve at once)