Hello all,

I'm not sure how simple this one is (most likely very simple)
but I'm looking to add a blur to Vops.
Anyone who cares to assist most certainly is thanked in advance.

here is my basic setup:

A “texture” vop runs through some other vops and is piped into the “Cf” of the output.

what I want to do:

Right before the network gets piped into the “Cf” of the output, I'd like to pull a blur on the texture.

I would have thought there would just be a “Blur” vop, but no.
So I assume this is rather simple if you are already have some knowledge of text based shading language. I've poked around for quite a while, and still haven't figured this one out (shader newbie).

thanks

Jim

Hi Jim,
So, you want to blur it after modifying the texture somehow? That's tricky (and likely expensive) in a shader, unless you blur it as the texture is referenced. Check the Filter Width parameter on the Texture VOP, increasing that will blur the image. There is also Filter Type which is the type of blur (Gaussian or Bartlett are typically used).
However, if you want to blur just before Cf… that's hard )

Cheers,

Peter B

Hey Thanks Peter!

Yeah I know about the filtering inside the “Texture” vop, I just wanted to have selected blurring for separate color channels… and a few other tricks.
I've been looking for examples where such a thing occurs, but have not been able to find any… do you (or anyone else) know of any?

Since I've got you here and you've been so good in helping to educate me in the past… I have another related question. :twisted:

In Vops I keep running into this “Grid Patterning” on my textures. At first I thought it was a matter of resolution, but I've had it happen with High-Rez “.pic” files before. In certain cases it's almost like someone took a “Graph Paper Lines” and placed them over the image.
I have included a couple stills where this is happening in a minor way.

stillA: A “Texture” vop run directly into the “Cf” of the “Output” vop. Notice around the right hand side of the outer eye, you can see this “grid” I'm talking about.

StillB: “Bump Map” to “Lighting Model” to “Output”. This time you can see it a bit more all over the surface.

thanks again

Jim

Depends on different things, from the image you're filtering to(more importantly) the type of filter you're using. Have you tried different types of filter? If you're using Box you'll definitely get this at higher values. Have you tried repeating on something other than the Mandril(it is what it is)?

Cheers,

J.C.

Hey Jim,
Make sure you are using .rat images!! Only .rat images filter correctly at render time. You can use “icp” on the command line to convert to .rat, or load them into Mplay then Save Frame and save it out as a .rat image.
Like John says, avoid Box filtering, Gaussian or Bartlett are more expensive but higher quality.
IMHO SESI should only provide .rat images since people constantly use .pic or .jpg images that are supplied, not realizing that they should be using .rat at all times in Mantra.

Cheers,

Peter B

Blurring like this is best done in comp. You can create a deep raster / AOV for your blur amount and use this as the mask channel for either a Blur COP or Defocus COP.

Peter, even PRMan relented and allowed their users to use .tif images. It is just that PRMan for the longest time only allowed .tx files that it has become a permanent way of life.

It sure makes sense to limit Mantra to only access .rat files though.

I'll be honest, although I'm certain using non-rat images is at the base of one helluva lot of support calls re:VOP filtering, I wouldn't be happy if you were forced to convert every single image to rat in order to use it. The whole rman/tx thing really pissed me off, actually. We're using *computers* here, for crying out loud. They're supposed to make our life easier, not harder! While I know there would be a performance hit, IMHO every renderer in the world should be able to accept (realistically) any image format in the world and if it needs to pre-filter the image in order to use it with the other tools(such as in-shader filtering), then do so automatically at some sort of default setting. At least the user won't be confused, and as they become more experienced they'll understand that internally pre-converting to rat is going on, they should be doing that themselves beforehand.

The prman tx mentality was locked in that old world mindset of all the end users being technical. Doesn't really help anyone, as they came to realize and added support for tif.

Cheers,

J.C.

Such a siimple idea/solution gets awful complicated in the implementation! You just can't say that everything should output images that support mipmaps always without exception. That would require one helluva whip! Any warnings and prompts are just band-aids. To do the automatic fix is still unacceptable to almost all large facilities with huge texture map requirements plus hardware isn't there yet.


I hear you John but unfortunately computers are not fast enough with vast cheep resources yet!

If I had 20 2k textures in my scene (not unresonable), just creating the image pyramids alone would hit me hard on the farm if converted at run-time. So to optimize, I would need a helluva lot of ram and completely negate the image tile optimizations in Mantra and PRMAN or cache the .rat's to disk then reference from there.
If the textures were just stills, it would be a simple case of cacheing the .rat's somewhere on disk. What if it is an animated sequence of maps though? Still get the hits.

Does Houdini interrupt the entire render process and pop up an exclusive warning: “Not using RAT image files, OK?” and when you come back from your coffee with the Director entering the door expecting to see pretty pictures… You get my point in that any warning is already a slippery slope to user hell. One that is dreadfully difficult to avoid, IMS.

I don't mind it if all the image based artists in the pipeline understood the significance of generating .rat's for Mantra and .it files for PRMan but to expect this in reality is nearly pointless. It won't happen nor should it really IMHO. It helps that the more recent cuts of Photoshop can directly generate .it files for renderman. No Photoshop can not save directly .rat files. Have to use a command-line tool right now or fire up mplay or our compositor and save a .rat from there. Just have a wrapper that trolls properly used project directories properly converting maps from whatever to .rat's at the farm's leisure. Just make them available and substitute at render-time. Sure large facilities can afford this.

The issue remains that each artist has “their” favourite image format and uses that to the complete exclusion of others. Wars over Tiff vs OpenEXR vs Tga, etc… continue to this day. Where does .psd fit in? Not very well.


Oh and yes, you would be correct in that the “use .rat” mantra has been sung quite a few times here in support whenever the user complains of flickering in the texture maps.

I don't think you're getting what I was suggesting…not for one moment would I say that this should all be automatic and standard. I'm just talking about handling it *by default*. I would hope(really really hope ) that any TD using Houdini in a production environment would know enough to preprocess their maps. Again, this is primarily to avoid two things:

1. You've added a tif map as a texture(perfectly reasonable), and you keep changing the amount of filtering in your shader and *nothing happens*. Bang fist on table. Hit head. Then remember why mantra isn't doing what you're asking of it, not giving you a warning or error…

2. Being forced to preconvert every last image that you're quickly testing by hand, when the rest of Houdini handles most formats out there. Format Facism.

I'm not suggesting auto-conversion is a model for a pipeline.

Cheers,

J.C.

Hey John,
Actually, Mantra _does_ warn you about non-RAT images, at least since H8, possibly H7 too.

Cheers,

Peter B

Smarty pants.

J.C.

Hello all,

thanks so much for the answers/clues!

Now I know.

And Jeff, yeah I knew about the COP solution…
won't work for my situation.
But thanks.

Jim