If you watch that section of the course it should be clear what's goin on. What's interesting is if I put a fit node after the bind (rest) node and change the Source Min value to -1, -1, -1 and re-render the tiling trick seems to work. But, what I don't understand is how Saber was able to make it work without the fit. I guess, I'm just wondering if SideFX changed something that affected this functionality between that older version of Houdini and 18.5.

I've been working my way through the free Rebelway asset creation courses [www.youtube.com] and the same tiling method is being used in both of the first two parts for COPs and VOPs tiling. However, I ran into a snag around 4:27:00 of the first masterclass, where Saber bakes out the flattened Torus to assist in tiling the texture. Perhaps, I did something wrong when rendering it out of Mantra, but my rendered texture looks correct, and I'm getting some bizarre banding when trying to implement it in the Tiling Part 2 section as well as the tiling section of the second VOPs course even though I seem to have everything hooked up properly. I posted this question in the YouTube discussion, but no response and it seems like someone else posted the same issue on there already. In any case, I wrote Rebelway to ask if they still had the assets, which they don't and informed me that the course was discontinued because they need to update it for use with the latest version of Houdini. So, I'm wondering if it's possible that SideFX changed something under the hood in Houdini 18.5 that's messing with this workflow, or am I just improperly baking out the texture?

This is more of a minor annoyance than anything else, but I'm working through part 3 of this free Rebelway asset creation course [www.youtube.com]
and around 9:30 I noticed a different behavior than in the video when trying to shade a VDB fog in the viewport with standard distant lights. It seems like the light gets cut off at the surface of the volume, and as far as I can tell it's not caused by the Arnold lights or anything else in the scene. The set up is super basic, and the same thing happens when building the scene from scratch in new projects. That said, it would be nice to have lights interacting properly with the fog, so I thought I'd ask to see if anyone has any idea what might be causing that. I know that this masterclass was created in a much older version of Houdini, perhaps as early as 16.5, so I imagine it might be a version difference, but it seems like a silly behavior to change. Might it be a bug? It still happens after updating Houdini...

I'm using Houdini 18.5.532 with Redshift 3.0.39 and I've been trying to check the Redshift render settings on some older Entagma tutorials, believe most were made in Houdini 17-17.5, so not that old, but if I don't have Redshift open I always get this warning with broken material nodes showing up in the mat context:

houdini bad node type found: redshift_vopnet in /mat

skipping unrecognized parameters...
...and, pretty much all RS parameters are skipped...

However, if I close down the project, switch to a Redshift layout and then open the project again, less parameters are skipped and the materials show up in the mat context, but I still get skipped parameter warnings for the materials like the ones in the attached screenshot.

At this point, the materials seem to render correctly, but I wonder if the skipped parameters are something I need to be concerned about? I imagine this is because the Redshift material nodes have changed slightly over the different Houdini and/or Redshift versions and parameter names have changed. Am I correct in thinking this?

That said, do I always need to have a Redshift layout up, when opening a project where RS was used? If I have Redshift installed it would be nice if Houdini just automatically recognized all the RS parameters. Would that be considered a bug? If so, should I report it here or on the RS forums? If not, do you have any tips for opening RS projects without breaking everything?

tamte

BenjaminMarkus
Figuring out how to translate the old for each subnet to the new for loops has definitely been one of the more confusing things I've tried to learn in Houdini

I bet

for learning purposes you can always unhide deprecated nodes (until they are fully removed) to be able to follow old tutorials
just open textport (Alt+Shift+T) and type
opunhide Sop foreach

then in Sop Tab menu you should see Foreah Subnet, even though you may have gone through this particular hurdle, it may be useful for other operators in the future as getting stuck can be demotivating, but of course learning the new stuff eventually is way to go

Yeah I totally know that trick and have used it in the past when I was following along and just needed something to work. However, in this case I really wanted to push myself and see if I could translate it. Definitely hasn't been easy, but I learned far more about how Houdini works than if I just used the old nodes and followed the tutorial exactly.

tamte
the old Foreach if you tell it to start at 0 and end at 0 , then it will do exactly 1 iteraton, iteration 0
the in the new For Loop Block you are telling it to do 0 iterations, so it will not do any and return nothing

so you may need to alter your expression to not and not subtract 1, I'm guessing

Thanks Tomas! I actually managed to get through most of first volume. I still have one little section left, and hopefully there's nothing too confusing in there. In any case, I was planning on posting fixes to all the gotchyas that seemed to have me stumped before. Figuring out how to translate the old for each subnet to the new for loops has definitely been one of the more confusing things I've tried to learn in Houdini, but I feel like I'm finally starting to get the hang of it. Fingers crossed it gets easier as I move forward through the next volumes.

tamte
because stamp() function is only valid during the cooking of the for subnet or old copy sop for that matter, you can't see the evaluated value as it's different every iteration so when observed it's not cooking at that moment and it falls back to the value specified as third argument, so in your case 0

new for loops allow you to observe a single iteration, by default is the last one, but you can pick a specific one so thats why detail() expression is able to resolve the actual value when observed as the metadata node still holds the values that belong to chosen iteration

otherwise your result in viewport seems to be the same, if thats the case, it appears to be working correctly during cooking

(also 3rd argument in detail() is component index, while in stamp() it's the mentioned fallback value, so while they may seem similar when both written with 0, they mean very different things)

Thanks for the quick reply. Yes this makes sense. I was actually able to get all the way through the first volume of this tutorial, but now I'm having an issue with only certain seeds working, and I've been comparing the two networks wondering if this could be the cause. But, since the viewport output is the same, this seems more unlikely.

As I move through both networks, the other thing that seems like it might be an issue is in the closed balcony section with the treat_body loop. I wonder if I replaced the opinputpath expression correctly by referring directly to the node which the previous opinputpath index 1 seemed to refer (find_closed_balc). They evaluate the same, both as 0, but in this case it seems to make all the geometry disappear.

Here's an example of my network and evaluation:




Here's an example of Anastasia's network and evaluation:

Does anyone know why the Seed detail("../metadata_stack_boxes","iteration",0) evaluates as 2 whereas the stamp("..", "FORVALUE_stackboxes", 0) evaluates as 0? I was under the impression they were supposed to be the same.


This is an example of my code:




This is an example of Anastasia's code:

Hi I keep getting this error when using the booleanfracture SOP with cutting planes on an alembic, and selecting or reselecting alembic paths in following attribute wrangles. Any ideas?

3384: Fatal error: Segmentation fault

Yeah I guess depending on the scene C4D might be a better option for rendering. But, I’m still gonna hound the Redshift guys about this stuff. These are really basic things that should work.

No worries. So weird that switching takes actually worked on your end, but in the end I wouldn’t have wanted to switch takes. I definitely want to render at 600 and not 300. 300 was just meant to speed up working…

I guess I just had to switch that NURBS geo to polys to get the BG cyc to show up properly. But, I’m still having trouble getting displacement to work on it. This time it shows up correctly in the Redshift IPR, but not in the bucket rendering. There’s just some ugly noise instead. I’m definitely gonna ask the Redshift guys about this, again…

However, I’m starting to wonder if it’s worth it to learn RS for Houdini if there’s so many annoying issues like this that work out of the box in C4D. It’d be so much faster and more pleasurable to export the smoke to VDB and render in Cinema. Also, the lack of the C4D shader node is kind of a deal breaker for me.

I use that node so often to mix Maxon noises and plug procedural textures into dome lights and other things… For being the procedural emperor, Houdini seems to be lacking in Redshift proceduralism…

Then again, there’s got to be a solution and if I just move back to C4D I’m not learning Houdini, which is kind of the point. Maybe there’s a way to achieve some similar noise mixing abilities in COPs, which is a context I haven’t really explored.

I’m still not sure how to plug procedural textures into a dome light though. I imagine that might involve some scripting. Would you happen to know how to go about achieving any of that functionality?

So, switching Render With Take to current didn't seem to work for me. The guys on the Redshift forum told me to disable the rest fields, which I did in the Initial Data section of the smokeobject and the rest field section of the pyrosolver. Once I resimmed that seemed to do the trick even with the take set to HQ.

However, does anyone have any idea why the ground plane cyc won't render? I thought it was maybe because I built it for Mantra, so I tried to rebuild from scratch and a normal grid SOP shows up in the Redshift RenderView, but as soon as I convert it to NURBS and add an edit SOP it disappears in the render. Pretty frustrating that it's so hard to render this basic stuff, but I'm sure I'm missing something obvious.

Interesting! I guess I'll have to be careful when using different quality takes. I wonder why Steven doesn't mention that as a potential gotcha in Volumes II? It seems like such a frustrating thing to try and troubleshoot when you're still learning because it works in mantra and then all of a sudden you switch to Redshift and the volume's huge and there appears to be no reason why. Anyway, I'll try messing with it again when I get a minute. Big thanks for taking a look.

Whoa! Thanks for looking at this one too. Didn't think anyone was gonna get back to me regarding this. Well the set up is pretty much the same as Steven's so I'm almost positive it doesn't have anything to do with the order of operations. I haven't changed any of that. I have however made some progress with a different camera and backplate, so it's no longer exploding, but I'm still not getting the kind of denting I want, and the ship still seems to be moving too fast despite it being much bigger in scale than the helicopter. I'll upload some flipbooks when I get a chance.

This is what one of the admins on the Redshift forums had to say:

“…these problems come from working with grids that have different voxel size inside the same vdb object, for example, the velocity grids. Redshift doesn’t support this, and although the plugin has some workarounds, they don’t always work.

Removing these grids or converting the whole volume from “vdb” to “volume” primitives usually resolve this issue…”

I don’t know anything about grid size to VDB voxel size relationship, so any information about that would be useful, or if anyone knows of a good tutorial that covers it that would be great. Anyway, I’ve uploaded the file. I assume you’ll have to re-cache everything. I hope that it’s not something as simple as caching it again once it’s set up in Redshift. Do you think switching from Mantra to Redshift could be the thing that cause the issue?

I’d love to. As soon as I’m done with this render, I’ll open it up again and have a look to make sure I’m not missing something. I can upload it with the cache, if you don’t mind downloading it, but I’m worried that the problem might exist within the cache itself. And, if you recache it on your end it might work. So, I wanna try and recache on my end even though it seems like that really shouldn’t be the issue. If it still shows up huge after the new cache I’ll definitely upload it cause I wouldn’t know where to go from there.

I definitely tried changing the cam1 back and forth between auto and cam1, but since there's only 1 camera in the scene I think it defaults to cam1 and I get the same result. It seems to be a really strange issue, or perhaps a bug. I've been using Redshift for a couple years in C4D now, so I'm no stranger to the way the renderer works, and at first I was excited by how well it seems to be integrated into Houdini, until I ran into this issue. I've never seen Redshift, in any app, show one object bigger in the render view than it is in the scene, but show all others the right size. I'm doing a render right now, so I can't post a screenshot proving this, but I'll try it again when my render's over.

Thanks for the reply, but I most certainly would not be posting on here if that were the case. As you can see in the screenshot. I’m using the Redshift Render view which has fixed scale set to 100% at 1280x720, and that custom desktop I made is specifically designed to fit that ratio in that exact space. So, zooming in or out on the render does not fix or change anything. Not only that, but the same thing happens in the Houdini Render View in different versions of Houdini. I feel like it’s got something to do with that volume cache because other geometry shows up correctly, including the source on the original setup I had going. For example, if I were to make a box it would also show up properly. And, as I said before it renders properly in Mantra. Or, perhaps the fact that I set it up in Mantra first caused some bug to show up. Either way, it seems like I should be able to easily convert a Mantra scene to a Redshift scene without having to rebuild and recache everything no?

I'm trying to learn Redshift in Houdini 18.0.499, but I'm having trouble rendering a simple smoke sim that I cached. Does anyone have anyone have any idea why it shows up bigger in the Redshift IPR than in the Scene View? It shows up correctly if I try and render it in Mantra. I tried a bunch of things including starting a new project and re-sourcing just the sim from scratch which is what you see in the screenshot. I also tried opening the scene in Houdini 18.0.460 but I got the same result.

Hi all,

I'm still pretty new to Houdini, but I offered to do my friend a favor by attempting to sim a spaceship crash for his short sci film. It was more of an excuse to learn RBDs in Houdini than anything else, but now that I've invested this much time I really want to make it work.

Anyhow, I started with Steven Knipping's Applied Houdini Rigids III Vehicle Destruction course and once I finished that, I tried replacing the supplied helicopter model with a spaceship that I modeled in C4D using a Kitbash kit, so the geometry shouldn't be an issue. It would appear that I'm very close to getting a workable sim because I got it crashing and denting with the original animation that I set up for the ship. However, I've been running into a bit of a snag if I change the crash animation.

For whatever reason, if I move the ship at all to match any of the tracked alembic cameras I was sent, either by changing the keyframes of the crash itself, or even by simply attaching the entire animation to another null and moving it in the scene, the ship totally blows up. You can see what I mean in the last 3 previews found in VFTV\render of the attached project folder. Maybe I'm missing something very basic, but as far as I can tell this shouldn't be happening, as my understanding is that the hard constraints I'm using on most of the ship aren't supposed to break unless I tell them to in the art directed cuts section of the frac SOP.

Anyway, the first preview in the VFTV\render folder shows that the sim more or less works with the camera matching but without denting, and the second shows the crash with denting but with no camera matching. But, for whatever reason I couldn't get the source tracked cameras working directly in Houdini, so I took them into C4D first, changed the resolution and alembic camera scale, and exported them at .01cm from C4D, and after that they seemed to line up in Houdini once I changed the camera view resolution to match. However, my troubleshooting brain is telling me that I might've messed something up during this process and perhaps the explosion is due to mismatching scene/camera scale issues with the alembic cameras that the tracking artist sent causing the sim to be calculated differently.

I'm not even sure if the C4D camera scale option affects the sim in Houdini and/or C4D, but scene scale certainly does, and if the imported camera scale is messing with scene scale, then maybe that's the problem. That said, I don't think that's the reason, because if I leave the original animation alone it seems to sim fine even with the new cameras. And, I believe I'm matching the scale correctly and using the right conversion which is supposed to be .01cm from C4D to Houdini.

I've also messed around with exporting different camera scales and scene scales out of C4D and importing the alembics back into Houdini using several different methods, all with the same result. But, I realize it might help me to know more about which software each shot was tracked in, so I'm double checking with the guy at Framestore, who did the tracks, regarding the scene scale conversions. I was thinking Syntheyes might be different from Nuke for example.

That said, I would be eternally grateful if anyone was willing to look at the project and let me know what they think the problem could be. My hope is it's something stupid on my part, and not some overly complex issue.

Here's a Dropbox link to a reduced version of the project with all the assets
[www.dropbox.com]

Regards and thanks a lot,