Really, how so? All you need to do is set you assets to be packed on disk for speed and turn the driver checkbox on with a path. Also, are novice users really needing to distribute renders to a farm/multiple machines (for most cases)?

Deadline works very well handling ifd generation and then running the mantra job automatically and you can get 4 licenses for free (I believe). Also, not quite sure how they would pressure an IT department?

I understand if you could just hit go and run it in a houdini that would be easier but there are (speed and memory) benefits to rendering IFDs much like there are using .ass files in Arnold. It honesty isn't a complicated thing to do once you get going and allows you to use unlimited mantra licenses for rendering at no extra cost and can work out quite economical as you scale up to a renderfarm.

Rich.

symek
BratThompson has a point here though. I don't mind using IFD files, I love them, they give us great deal of flexibility, but to take full advantage of them, you need a lot of scripting - building entire pipeline around them. They are completely redundant practically wise for novice users. SESI used to have hbatch license suitable for running only rendering, also big companies having site license of hbatch don't bother with IFD files afaik.

Last but not least, managing IFD files puts a lot of pressure for IT department, which, again, makes use of Houdini/Mantra rather harder than easier.

I understand if you could just hit go and run it in a houdini that would be easier (…)

That was the point I was making. Thank you.

Richard Costin
Really, how so? All you need to do is set you assets to be packed on disk for speed and turn the driver checkbox on with a path. Also, are novice users really needing to distribute renders to a farm/multiple machines (for most cases)?

Yes, novice people, like small houses starting using Houdini have problems with adoption of two stage rendering. I've encountered it many times, since I was hired helping them installing Houdini in their pipeline. Doesn't bother you, doesn't bother me, bothers them.

Also, not quite sure how they would pressure an IT department?

Packing assets is a perfect situation, often not possible (not to mention bugs, which might force you to unpack your assets in a middle of the show). If you work with assets with multiply groups and shaders applied to them coming from Maya, rest assured sooner or later you will be forced to unpack geometry, or your artists will find some reason for you. IFD requires scratch, scratch has to be cleaned, cleaning isn't that easy on snapshot systems, ergo either scratch requires second file system or scripting for cleaning with elevated permissions on a server, which might not even be on the same location or might be mirrored on remote location. List continues.

People are complaining that things might be easier to setup for them as they are today. I just wanted to give them support, so if we've already reached consensus (first line above), could we not continue?


edit: I meant not continue on point out how great IFD files are, since we all already know that.

symek
installing Houdini in their pipeline

trick is to just bypass it, so many ‘problems’ just go away.

I think I made my point regarding IFD's, but here's a real-world example I just encountered where the two-step rendering pipeline cost me a day's time. If you know a better approach, I'd love to hear it. Here is what I did.

I'm working on a sim with a pool of bubbling lava. It's a 900 frame long, reasonably high-detail sim. My workstation has been meshing it since the night before, resulting in a several TB geometry cache. Most of the day has been spent getting my material to look good. I'm hoping to render it overnight. It's late in the day, but I finally get the shader looking good enough for a test render, so I generate my IFD's and send them to Afanasy. A few minutes later, I load up the few frames I've gotten back from the farm, and notice that the UV's are unstable and twitching about. A little bit of research indicates that adding a UVSmooth node to the mesh might solve the problem.

The thing is, I can't just add the UVSmooth node and resubmit to render. I've gotta unpack that geometry, apply the UVSmooth, and re-cache it. All that, and I'm still not sure it will fix the problem. With several TB of mesh data, that didn't finish in time for me to resubmit to the render farm before I had to leave, putting me a day behind.

I don't mean to belabor the point. Yes, spending money for a few Engine licenses would ease the problem, so we might do that. It's still an extra complication that could be hidden away and automated so that I can spend more time being creative and less time administrating processes.

Hi,

Anyone got the chance to compare 16 and 16.5. in terms of speed.

Cheers

Not about speed but now when you increase samples the noise is reduced more easily.
Before this release to get glass and clear coat without noise was a big problem.

wildruf
Hi,

Anyone got the chance to compare 16 and 16.5. in terms of speed.

Cheers

I did a test with simple scene and various types of materials. I found 16.5 was between 8% and 30% slower than 16.0 depending on rendered image size and material complexity. However 16.5 was often much less noisy at the same settings and had more pleasing distribution of noise. So the same-same comparison has to be taken with a bit of consideration.

Hi,
i used 16.5 and its indirect refection is much faster and light sampling is much more pleasing. Like jsmack said same settings much better quality.
The scene that took 15 minutes to be almost acceptable now takes 10 minutes and is great. To get the same quality as before it would only render 5 minutes per frame. Whereby this is not easy to compare. The new light sampling noise looks better even with more noise.
I do like the improvement.

Maybe i find some time on the weekend to do an interior scene test.

greetings

Olaf

BradThompson
The thing is, I can't just add the UVSmooth node and resubmit to render. I've gotta unpack that geometry, apply the UVSmooth, and re-cache it. All that, and I'm still not sure it will fix the problem. With several TB of mesh data, that didn't finish in time for me to resubmit to the render farm before I had to leave, putting me a day behind.

Yeah, but even if there wasn't an intermediate IFD generation, you would still have to spend the time loading and processing that mesh. That would have to cook as some sort of pre-render phase regardless.
If this was a slow, single-threaded process, having a few engine licenses would potentially make things way more efficient, if this is decoupled from the render phase. Your many-threaded render node would not be locked waiting for a single threaded process to finish. Instead, pre-processing can be distrubuted and processed in parallel.

yeah, but your farm usually has way more renderblades then IFD generation machines. I would rather send scene that needs to be loaded and cooked to 60render blades then to 2IFD generating machines that will be cooking longer then i can render a shot.
Instancing is fine, if you can fit into memory. Otherwise you are stuck.

Hi of every of you.
Thank for that that you write.

If you have the best scene of the world, if you see all the parameter and how they made the tweeks. You can no see where the inspiration come from. That you say, or no say, i feel something good (.the good render.)
mantra have the two world you use the in build materials
And you build or tweek them. i think this is really important the whole point.
For improve the speed, depend of scene… But… The game workflow , composition technique can help. The inspiration that thing that how you see , take a look around you this come from other place and that is all.

Hi very interesting thread. I'm a freelancer with a 13 slaves render farm now still using max+V-Ray and hoping to switch to Houdini + ?. Maybe when v-ray4houdini will be ready I will use it. But I look at what places like Main Road Post [www.mrpost.ru] do with Mantra and I'm really eager to learn Mantra too even though my first test with it were noisy slow and discouraging. I'm happy to read some posts here explaining how it can still be a very useful renderer and we can also couple it with redshift for some jobs were speed is the most important factor.

Well there is an important fact. If you feel comfortable, your videos or pic make happy or something like that. Your creative see Have something to show.
buuuut how hard is climb to that land, where the creativity spreed.

the fast render time wooow. But make a good render how time take you.?

Here is my take on Mantra

Using it pretty much full time for around 7 years now. Strictly for FX rendering, Volumes RBDs and Particles.

Apart from these effects having their own workflows for optimized rendering, I have learned quiet a lot of tricks meanwhile.

IFD workflow is just a licensing issue of course, mantra executable does not need houdini to be able to render just like ass or rib. SideFX doesnt do site licensing (AFAIK), but engine licenses are god sent and the fact that Mantra is literally free just makes up for it.

There is quiet a deep explanation on instancing and rendering packed objects in the documentation

Packed objects are god sent, and even now with Mantra being able to manipulate Geometry with Mantra Engine Procedural, makes it even better.

But again, I work in a Studio Enviroment, however If I was a freelancer Indie comes with +3 engine licenses, and 3+PCs are defienetly well worth it for the price they offer.

Would love to see similar comparison with the next version of Karma on Houdini 20

jomaro
Would love to see similar comparison with the next version of Karma on Houdini 20

Necroposting king