Bevel Edgers Shader For Prman

[mistrot]

hey,

I'm looking for something like the mia Round Edges shader for renderman (baiscly, rounds the normals at the edges).

Cheers,

Nick

[joojaa]

Well i havent seen one for download but one is possible to make. Oe could approach this in 2 ways, with raytracing and some fancy export time encoding.

This said you can just model it in during export (so that after you have this in place you don't need to make it), as prman is VERY fast for dicing compared to mentalray. So you could get a real bevel for the price of doing it in shader. Whereas shading is more expensive in prman (it works upside down in a way, much like your graphics adapter)

[mistrot]

I'll tell you bit more why i want this, and maybe there are better ways to approach it.

I basicly need objects to "blob" together, and the round corners does a nice normal blur to give this effect. We can kind of do it in prman using custom normal passes, but it's bit slow and artifact prone. The mia round corner shader just seems fast as.

Cheers,

Nick

[joojaa]

QUOTE(ndeboar @ 04/29/09, 02:34 PM) [snapback]306991[/snapback]
I basicly need objects to "blob" together, and the round corners does a nice normal blur to give this effect. We can kind of do it in prman using custom normal passes, but it's bit slow and artifact prone. The mia round corner shader just seems fast as.

Then i would use metaballs and implicit surfaces. As prman has a much wider range of primitives in this sense and they DO merge in together even very complex blobby implicit's can be made. You could even use use the api to construct your own implicit surfaces if you wished so need a hand shaped primitive no problem

And this is not just a visual trick the surface would actually be this shape.

QUOTE
The mia round corner shader just seems fast as.

You cant compare them this way. They work totally differently. So in mentalray its cheap to do shader code. Whereas in prman its VERY cheap to do things in geometry. So cheap in fact that one would hardly ever send prman faceted polygon surfaces. Because it would basically be a waste of time. As you can render a subpoly accurate parametric surface for the price of one polygon quad. Especially sonce you could in essence ditch raytracing with geometry approach.

So adding a bevel that truly round is Cheaper than sending 12 more polygons. Also sending in polygons has HUGE problems with surface derivates such as normals since you cant approximate stuff at discontinious edges.

So using prman also means you need to model differently too. For example you should avoid surface intersections in prman, the renderer gets a slight speed hit out of this and just uses up valuable time reducing until they no longer intersect.

[mistrot]

hey, thanks for the reply.

A subd surface that kinda acted like a blobby would be brill. No idea how i would do that. Could you point me to resources?

Cheers,

Nick

[joojaa]

QUOTE(ndeboar @ 04/29/09, 02:56 PM) [snapback]306993[/snapback]
A subd surface that kinda acted like a blobby would be brill.

You can do that if you happen to use rfm pro and a relatively good TD in house, doing implicits is described in the documentation for renderman pro server.

Even if you can not you can guesstimate your surface with a lot of blobby primitives. Which by the way have all sorts of nice things about them such as ability to specify texture cords to them, tell what surfaces blend with ounly selected subset of that surface etc etc..

[mistrot]

We are using RMS 1.0, so we have access to all that.

I heard they tried before to render out a point cloud, convert that to blobbies, but it was taking like an hour a frame to get good results.

Getting something that just smooths normals at hard edges would be the "easiest" thing to implment atm.

Nick

[joojaa]

QUOTE(ndeboar @ 04/29/09, 03:53 PM) [snapback]306999[/snapback]
Getting something that just smooths normals at hard edges would be the "easiest" thing to implment atm.

then write a shader that traces a probe out of the surface an perturbs normal based on distance and normal direction.

Anyway i tested this with mentlaray and it don't work out every well with intersecting surfaces. because it confuses wich side to turn to. So your shader writer needs to be more specific how he does the probe. But basically its like a occlusion probe that just asks for nearby normals. Instead of color or hit, one can omit the rays that are perpendicular to teh surface tough and opt for probes around the normal mostly instead

QUOTE
I heard they tried before to render out a point cloud, convert that to blobbies, but it was taking like an hour a frame to get good results.

Well a point cloud is not the best possble geometry type to split this data from. However thepoint could data can be driven into a brickmap. Now this gives you 2 NEW options i didnt think about:

1 just like the point cloud based final final gather make the explicit surface field out of this. Then youd have in basic just one blobby particle and it should basically be justa lookup for polygons (the api can polygonal just as long as you can provide a solid fallof field), so just do falloff the values as brick creation. Now you could Also render this deirctly out as samples as the rendering fo comlpex geometry directly out of the brickamp see the provided examples in manual. Both methods would be cheaper than a BIG blobby field. I actually tested this once when i still had access to proserver and it worked reasonably well for my geometry.

Second you can use the brickmap for the normals by averaging nearby samples in the point cloud. The good thing about this is that it doesnt flood out to places where you have a near contact but not quite.

Third if you have the manpower tunr surface into nrbs at export time and do a round at that time. This too works very well, but doesn't motion blur

[mistrot]

ah, great stuff. thanks again.

yeah, i read about a nurb's approach to achieving this affect, but where all pollys.

I will trawl through your comments and post if i get some good results!

Cheers,

Nick