Hi all,

I'm trying to render to several outputs at the same time, and perform multiple takes on those outputs. In the example scene shows more clearly what I mean, I have two sub-takes (each shows a different primitive), and a Wedge node that is set to render both of these takes. In the /out you will see a Wren node plugged into a Mantra node, the idea being that if I set the Wedge node to render using the Mantra node as an output driver, the Wren node that is connected into it should also render. But it renders using the wrong take. If you open the attached file and click on ‘Render Wedges’ of the /out/wedge1 node it should render the Wren node, then the Mantra node to MPlay. You can see that the Wren node always renders the same output.

I see in the documentation there are instructions on how to wire up multiple nodes to make them all render in sequence, but this doesn't seem to work at all where takes are concerned. Am I doing something wrong or is this a bug?

It appears that I just need to gather the motion data for each point one after the other.
So with that in mind…how do I access the position data for an arbitrary point at an arbitrary time?

Hi all,

I've been trying and failing for two days to get the results of a particle sim into another package. The particle cache format is documented here:

http://forums.newtek.com/showthread.php?129146-fcache-specification&p=1255059&viewfull=1#post1255059 [forums.newtek.com]

The format is roughly:

As you can see the format requires data for each particle to be in sequence, which is an issue, as at each frame I can iterate over the points, but I cannot possibly know how many frames each particle lives for at some random frame.

Does anyone have any ideas on how to do this? I've tried using a shuffle CHOP to rearrange the data, but it's just too slow to be useful.

Hmm. Interesting. Next time I'll have to plan ahead knowing that this happens

Hi all,
I find myself in a situation where I need to use a 64bit integer in order to create an unique id (and there is no other way around it). However, wrangle nodes and VOPs seem to be limited to 32 bit, so the question is - how do you perform calculations on 64 bit integer attributes?
I've attached a simple scene that demonstrates the problem, in which you can see that the attribute ‘a’ becomes screwed up because it exceeds a 32 bit int, even though teh variable is 64 bit.

Thanks again for the reply. I'll have to poke around a bit and see if I can find out what the difference is. It may be a case that they're essentially the same, but the packed primitives are a relatively new feature.

As for the distributed rendering/geo caching thing, it's a bit of a shock that I'm now going to have to have hundreds of gigs of drive space for something that previously took none D: I understand that Mantra and Houdini are sort of separate entities here. Houdini processes all the inputs and internally creates an IFD, then passes it to Mantra to produce the image. The way other apps I've used work is that there is essentially a version of the application without an interface which performs the distributed rendering, which takes all the inputs (models, animations, deformations, and everything else that was constructed in the app) and processes it again, on the fly, to produce the image. I guess this will take some getting used to

Thanks for the tips Just a few more questions if I may…
So the ‘Delayed Load Geometry’ checkbox in the file SOP isn't anything to do with the delayed load procedural that you're referring to?

Secondly, going back to the IFDs…if I have a mesh, say a complex character for example, and that is rigged with bones and other deformations. In order to render that I have no choice but to save out the same piece of geometry (albeit deformed) for every frame? Or is that precisely what the delayed load geometry does?
I'm having issues getting a proper handle on this as it is completely different from any other application I've used

moogtastic
You are correct, you'll have to write out your geometry as a final step. Note that if you don't, you're still essentially writing out your geo into IFD files anyway so it's not like you're saving disk space. What I would do is use a delayed-load procedural right after the file cache node and your IFD-gen should be very fast because they'll contain links to the geometry on disk rather than containing the geometry itself. I'm not sure what the advantage of using packed primitives are, but delayed load procedural works very well in our pipeline

Hmm, I must have done something wrong as I tried that before. If I check the ‘delay load geometry’ on the file SOP shown in the previous image then the geo is just written to the IFD. Unless that's expected behaviour in that situation?

Edit: I've just looked into delay load procedural and all I can find is this: https://www.sidefx.com/docs/houdini14.0/nodes/shop/vm_geo_file [sidefx.com]
Which appears to be a shader. And now I'm just confused.

That certainly does reduce the ifd size, yes. However, here's an example of the kind of problems I'm having…
I saved out a bunch of geometry in one geo file that contains groups. It was a particle simulation…sort of that lasted about 250 frames. My final animation requires that simulation to start at about frame 200, making the whole length 450 frames. I also wanted to displace things slightly based on groups, so I cannot load it as a packed primitive. So from what I've learn it seems I have no choice but to write out another sequence of geo files costing another 30gb and time
I've attached an imagine in case my ramblings above were incoherent.

So…was there no way to do this without writing out geo again for every one of the 450 frames?

Hi all,

So, I'm having a hell of a time trying to get mantra to render using backburner. One of many issues I have on the remote machine is that mantra will not render because it cannot attain a license. All I get is:


Ok, fine. It should get the license from the license server running on my workstation. But I cannot get the remote machine to do this. It is apparently connected to the correct license server (see attached image)…it just doesn't work.

Also, all firewalls are turned off. I've read everything I can find on the subject and am now completely out of ideas.

I submitted the question to SESI yesterday, but not gotten a reply yet.

circusmonkey

My geometry is constantly changing so the opportunities to use packed disk primitives are quite rare, so IFD generation usually has to evaluate quite a few nodes

If that's case I wonder what will happen to your velocity values > with a changing point count

Rob

They are completely borked.
I either have to use reelsmart motion blur in post and just hope it does a good job, or calculate my own consistent unique id attribute to figure out the vel. The former can mess up completely sometimes and there's nothing you can really do about it, and the latter takes some not insignificant planning.
Fun!

blackpixel
I don't know about backburner, but most render managers allow you to have multiple jobs on one machine. This would automate the process you do manually now.

Yup, but as I only have the one license, I cannot give that task to a farm node - they can only use IFDs, not create them
I'll have to figure out a way to get the IFDs written as efficiently as possibe, be that caching geo to disk and loading a packed priomitive, or scripting the use of hbatch on my one licensed machine to start multiple copies and generate IFDs

Hi rob,
I have no idea about Engine…I have a license for Houdini only (not Houdini FX), but in any case it's locked to one workstation. I can use hbatch to open the hip and export, but it still suffers from the same poor output speed. This is why I had to use hbatch to open about ten copies of the scene and render out simultaneously.

As for backburner, I've yet to get it to work over that, but in principle it's quite simple (just calling mantra.exe ifd_file).

In regard to teh output time, I think I'm just using Houdini for unusual shots. My geometry is constantly changing so the opportunities to use packed disk primitives are quite rare, so IFD generation usually has to evaluate quite a few nodes

Hi all,
I'm trying to set up mantra with backburner to get some rendering done over our farm. That's the end goal anyway.
However, to do so I need to create IFDs for Mantra to render, and this process is a really significant bottleneck in the whole process because 1. The IFD creation is very slow and apparently single threaded, and 2. The IFD file size is quite significant.

While I can live with the file sizes, the real killer here is the workflow of having to have one machine create IFDs, which on my current shot takes approximately thirteen hours. Does anyone know why this extremely important step seems to be single threaded? To make this process feasible at all I had to use hbatch to manually open up ten copies of the scene (each eating RAM) and split up the IFD creation between them.

So, is there something I'm missing here? Are there some tools to make this process less painful? This is the first thing in Houdini that has frustrated me

Edit: I don't think I can make the IFD creation any quicker, as the geometry is dynamic, so different on every frame.

You have nothing that tells the detail attribute that it should take the value you provided with the slider. Currently they are two unrelated things: the detail attribute, and a slider control.

Try putting down a detail wrangle node and using it to set the value of your attribute to that of the slider
If the Null is on the same levels as the wrangle node.

Ah…I think we've come full circle. My original post was about how you can use the hair normal shader, but things can go a weird when you try to use displacements, but on a primitive sphere, everything works great as you get actual geometry

…and the attachment.

mark
By default, mantra will shade just the centerline of the open curves. There's a setting to change it so that it shades curves as surfaces. I think vm_curvesurface is the setting. Memory will go up a little, but not as much as sweeping NURBs.

Hi Mark,
I have tried that, but the setting seems to make no difference.
I've attached my test scene, and you can see that the setting does not change the output.
Is there something I'm doing wrong here?

I was thinking more along the lines of implicit tubes, but the replies I got over at odforce here [forums.odforce.net] just say that Mantra currently does not support this, which is a shame.

@robsdesign I tried using the sweep with nurbs, but the structure is quite large and the render times just went through the roof. I'm not sure why…maybe the combination of nurbs and displacement. In any case it's nmot usable

@BabaJ See above I'm trying to keep to just implicit tubes from curves.

I'll put in and RFE for this.

Hi all,
I was wondering if I was missing something when it comes to render curves as tubes. I know that if you have a curve, you can set it's width attribtue and that will make it render as a strip. Then, using a hairNormal shader you can make it appear as a tube…ish. However, this is only a shader effect, so when it comes to rendering displacements on the tube, things can look pretty odd.
It is possible to render points as spheres, complete with actual geometry that can be displaced properly…but is this not possible with curves?