New in mental ray Version 3.5

[Eugenio]

This feature list seems too "lean", IMHO...

However, the Final Gathering stuff sounds really interesting...I just wanted that it not to be so sensitive to the amount of bounces (it affects too much the render time), in this area Vray is just unbeatable.

Let's see how all this features will be implemented in our beloved packages (in my case, 3dsmax)...

Regards,

Jr.

[EternalArt]

damn .. just a little features .. and nothing very interesting .. ??

[ThE_JacO]

damn .. just a little features .. and nothing very interesting .. ??

excuse me?
how is finally having proper CC surfaces and lightlinking for instances "little features".
and that is forgetting about even more important stuff like mental mill and metaSL.

they might seem little features if you don't know what you're looking to maybe, but they are fairly important holes that are being filled.

[mech7]

automatic final gather would like to see how easy that is :)

[ashrafazlan]

what??! where is the ultra fast high speed subpixel displacement rendering feature :deal:

[shingo]

What are you nuts?

Take these two features alone.

- Catmull-Clark polygon meshes ("ccmeshes") have been introduced. This subdivision surface type uses Catmull-Clark rules for smoothening and supports polygons with arbitrary numbers of vertices.

This is totally awesome!! People who have been using Renderman compliant renderers know how ground breaking this will be for users. If I am correct, it basically means that you no longer have to subdivide meshes to make them perfectly smooth. You define a mesh as a Catmull-Clark mesh and MR will render it as a sub-d object. That's a massive feature alone.

- A command line option -reload has been introduced. If this is specified then mental ray attempts to avoid keeping geometric objects read from the mi file in memory permanently, but re-read them from disk as needed.

It sounds a like it might be a little limited as a first release, but the potential here is enormous. This sounds to me like the first step towards the equivalent of RIB archives, which again, any Renderman user will tell you, is one of Renderman ‘smost powerful, and useful features. Loading mi objects into memory only when they are needed as opposed to having to load them every time makes the rendering so much more scalable

damn .. just a little features .. and nothing very interesting .. ??

[EternalArt]

I just want to say .. we are expect more than 7 improvement in the new version , since version 3.4.6 has released , anyway as mental images said (it's most important changes) , that's mean there are more features.

and I wish softimage implement all the mental ray shaders in the new version .

[ulb]

What are you nuts?

Take these two features alone.

- Catmull-Clark polygon meshes ("ccmeshes") have been introduced. This subdivision surface type uses Catmull-Clark rules for smoothening and supports polygons with arbitrary numbers of vertices.

This is totally awesome!! People who have been using Renderman compliant renderers know how ground breaking this will be for users. If I am correct, it basically means that you no longer have to subdivide meshes to make them perfectly smooth. You define a mesh as a Catmull-Clark mesh and MR will render it as a sub-d object. That's a massive feature alone.
I'm also a bit disapointed seeing that feature list as i was expecting more, but that catmull-clark thing (if it's really what you described :) is priceless.

[mdee]

damn .. just a little features .. and nothing very interesting .. ??
Hmm, catmull-clark meshes itself are a big thing. I'd not call those features "little".

Also, looks like mr got one button fg solution as lots of people requested.

Personally I can't wait.

[mech7]

Also I hope SSS Shaders get easier.. as they are pretty tricky and clumsy to setup in maya :(

[victor]

Hmm, catmull-clark meshes itself are a big thing. I'd not call those features "little".I don't see it. I mean, this isn't groundbreaking. It's an efficiency enhancment. In fact most of them are.

Besides, in Maya, we have subdivs anyway. Does XSI not have an equivalent?

I'm all for a more efficient renderer, but none of these features let me do anything new or anything to get really excited about.

I get excited about new material and light and lens shaders or more control over existing ones. I'm hoping that the Maya connection in the new version will have these kinds of things that aren't mentioned in the base MR feature list.

[seifneo]

i wish that it will have a very fast and furious :scream: .....Motion Blur !

[francescaluce]

I get excited about new material and light and ....so you'll get very excited during siggraph. :)


ciao
francesca

[ThirdEye]

proper CC surfaces.

i wonder how they managed to get rid of this patent problem

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=9&f=G&l=50&d=PTXT&S1=(%22subdivision+surfaces%22+AND+pixar)&OS=%22subdivision+surfaces%22+AND+pixar&RS=(%22subdivision+surfaces%22+AND+pixar)

[shingo]

You don't see it probabyl because you have not used it in production.

Maya subdivs are crap, let's face it. And why woudl you want to work with them as opposed to poly meshes, whcih are so much easier, and faster? Why not let the renderer do the job? The memory implications alone are huge and frankly, this is huge. Yes Renderman renderers have it already, but those wanting to stick to MR, will be elated.

Again, if you are not getting excited about them, it's probably becasue you don't appreciate the implications for larger productions. Mental Mill and MetaSL are hge in thrie own right, but they are merely listed as a single item.

I don't see it. I mean, this isn't groundbreaking. It's an efficiency enhancment. In fact most of them are.

Besides, in Maya, we have subdivs anyway. Does XSI not have an equivalent?

I'm all for a more efficient renderer, but none of these features let me do anything new or anything to get really excited about.

I get excited about new material and light and lens shaders or more control over existing ones. I'm hoping that the Maya connection in the new version will have these kinds of things that aren't mentioned in the base MR feature list.

[shingo]

Patents are only valid for 5 years.

i wonder how they managed to get rid of this patent problem

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=9&f=G&l=50&d=PTXT&S1=(%22subdivision+surfaces%22+AND+pixar)&OS=%22subdivision+surfaces%22+AND+pixar&RS=(%22subdivision+surfaces%22+AND+pixar (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=9&f=G&l=50&d=PTXT&S1=%28%22subdivision+surfaces%22+AND+pixar%29&OS=%22subdivision+surfaces%22+AND+pixar&RS=%28%22subdivision+surfaces%22+AND+pixar))

[ThE_JacO]

i wonder how they managed to get rid of this patent problem

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=9&f=G&l=50&d=PTXT&S1=(%22subdivision+surfaces%22+AND+pixar)&OS=%22subdivision+surfaces%22+AND+pixar&RS=(%22subdivision+surfaces%22+AND+pixar)


that patent isn't on adapative SDS, that patent is about creasing SDS by a particular implementation and algorithm.
that is also the reason why Houdini's mantra has had support for SDS for ages, but the actual app would only export creases to PRMan and not to their own engine.

even then, there are ways to get around it anyway, and some engines already did (3delight has more efficient and non patent breaking options then I've seen in PRMan)

[martinw]

Patents are only valid for 5 years.

Cough. I think not. 14 or 20 actually:

http://www.uspto.gov/main/faq/p120013.htm

[ThE_JacO]

20 for the particular patent we're talking about here if I remember correctly

[cpan]

hey ho cool stuff in there :)
can't wait to see what Zap has been cooking for us this year :D
(an archviz shader? hehe)

[SheepFactory]

But can it render photorealistic images like maxwell?



\hides :)

[ThE_JacO]

But can it render photorealistic images like maxwell?



\hides :)

yes, the downside is that it won't allow you to take a week off while waiting for it to render ;)

[NUKE-CG]

Zing!

And most software companies love to add "Enhanced render times" "better memory management" etc.. I'm wondering why they haven't listed that here. I'm hoping they don't believe those attributes are New to their software and are just optimizations, and not that they haven't gained significant more speed to warrant telling anyone (yeah, I'm talking MB).

[mech7]

And it has that indoor lightning button too I suppose :D

yes, the downside is that it won't allow you to take a week off while waiting for it to render ;)

[shingo]

They are implementing BRDF materials into MR 3.5, so that should go a long way towards better simulating how materials realistically interact with ligtht.

But can it render photorealistic images like maxwell?



\hides :)

[Stahlberg]

And most software companies love to add "Enhanced render times" "better memory management" etc.. I'm wondering why they haven't listed that here.
I guess because they wrote that list is only "the biggest changes"?

[Chris-TC]

Catmull-Clark polygon meshes ("ccmeshes") have been introduced. This subdivision surface type uses Catmull-Clark rules for smoothening and supports polygons with arbitrary numbers of vertices.

This is totally awesome!! People who have been using Renderman compliant renderers know how ground breaking this will be for users. If I am correct, it basically means that you no longer have to subdivide meshes to make them perfectly smooth. You define a mesh as a Catmull-Clark mesh and MR will render it as a sub-d object. That's a massive feature alone.


I'm just curious, but how is this different from specifying Catmull-Clark rendertime subdivisions in XSI? It seems like mental ray is understanding this already?
Surely I must be missing or misunderstanding something?

[shingo]

In XSI, and in other apps like Lighwave and Maya, the subdivision is done by the 3D application. So essentially, XSI takes your poly mesh, dices it to the specified sub-d level and sends it to the renderer. Raf might want to better explain this in more technical terms.

Anyway (again Raf chip in any time) by including the SDS geometry definition in the renderer, the above step is bypassed. The renderer understands that what it is being provided is the SDS cage and so it generates the Catmull-Clark surface.

The wonderful thing about this is that, not only is the memory requirement reduced significantly, but that the SD surface is perfectly smooth, not matter how close to it you get.

I'm just curious, but how is this different from specifying Catmull-Clark rendertime subdivisions in XSI? It seems like mental ray is understanding this already?
Surely I must be missing or misunderstanding something?

[SheepFactory]

They are implementing BRDF materials into MR 3.5, so that should go a long way towards better simulating how materials realistically interact with ligtht.

I was just joking btw , I know MR is more than capable of creating any type of render.

[Osaires]

mentalray already have the subd approximation (sub at rendertime), so whats the difrent between the current one and the new Catmull-Clark subdivisions?

btw. I cant wait to get my hands on this new version though :)

[shingo]

Not the same thing.

Mental Ray supported SDS via it's own Mental Matter library, which no one adopted. Nort sure wha the reasons were for it not being widely, but in any case, it went nowhere.

mentalray already have the subd approximation (sub at rendertime), so whats the difrent between the current one and the new Catmull-Clark subdivisions?

btw. I cant wait to get my hands on this new version though :)

[cpan]

Not the same thing.

Mental Ray supported SDS via it's own Mental Matter library, which no one adopted. Nort sure wha the reasons were for it not being widely, but in any case, it went nowhere.


hmmm, in Maya there is an mentalray SDS at rendertime algo, and i'm pretty sure XSI has one too. Tough the new Catmull-Clark should remove some limitations that the current one has, i think...

[Chris-TC]

but that the SD surface is perfectly smooth, not matter how close to it you get.

Seriously? That sounds awesome :eek::thumbsup:

[shingo]

Is that for Maya's SDS or the poly subdivision?

Again, Raf can probably shed more light on this, but from my guess is that Maya, like XSI, is subdividing the poly mesh and then sending it to the renderer. If this was an existing feature, then it makes little sense why Mental Images would list it as new.

hmmm, in Maya there is an mentalray SDS at rendertime algo, and i'm pretty sure XSI has one too. Tough the new Catmull-Clark should remove some limitations that the current one has, i think...

[poly-phobic]

i thought thats what the SD approx in maya and geo approx in xsi was doing at render time;
and its view dependent, so it will subdivide as needed to keep it smooth given the distance from camera?
so in retrospect, the app is not subdividing, it the renderer thats doing so at render time
am i wrong?

or is the new catmul clark algorythm doing something different than the subd approx that already exist?

but still, any new or better feature is welcomed.

[ThirdEye]

Read this if you want to understand how SDS should work

http://www.plastickitten.net/wordpress/essays/reyes-primitives-some-philosophy/

[shingo]

No it's not the same thing. Now that Catmul Clarke is included, MR has an new geometry class that it accepts, just like curves, poly meshes and nurbs.

SD approx and geo approx asks for an input sub-d level to be specified, correct? In other words, the poly mesh will only be subdivided as many times as as it is asked to, but it is still done before sending it to MR. MR just reads in the high res geometry and renders it as a smoothed poly mesh. The object remains a poly mesh object throughout these steps.

The catmul clark algorythm takes the poly mesh, and uses it as a cage to create the limit surface. If it works like PRman or 3Delight, there is no tesselation involved. Unlike Geo or SD approx, it is view independent - it takes the same amount of memory to produce a perfectly smooth surface regardless of where the camera is. In this case, the low res poly mesh object is converted into a Catmul-Clarke SDS.

Make sense?

i thought thats what the SD approx in maya and geo approx in xsi was doing at render time;
and its view dependent, so it will subdivide as needed to keep it smooth given the distance from camera?
so in retrospect, the app is not subdividing, it the renderer thats doing so at render time
am i wrong?

or is the new catmul clark algorythm doing something different than the subd approx that already exist?

but still, any new or better feature is welcomed.

[DimitrisLiatsos]

Errr..

Does anyone know if they fixed that bug with animated visibilty of an object ...
(it stays visible all the time.....) ??? :scream:


\hides...

[gga]

SD approx and geo approx asks for an input sub-d level to be specified, correct?

You are wrong, shingo. mental ray has supported subdivision surfaces as a primity type since v3.0 (3+ years ago). maya has shipped with the subd portion of mental matter since v5.0 and this gives you accurate tesselation of surfaces if you use a view approximation with a length of 1 or less, just like with nurbs or any reyes renderer.
XSI does not ship with this library and implements its own polygonal mesh subdivision that has always been catmull-clark compatible but not view dependant (why Avid never ported their code to a geometry shader and made it view-dependant is beyond me, really). Same with 3dmax.
The main difference is that mray's algorithm used in mental matter was not catmull-clark. It was a propietary algorithm that resulted in slightly different shape to catmull (a tad less smooth). This algorithm was a tad better than LW's metanurbs but a tad worse than Catmull. Most users will not really see the difference.
Also, mray's previous algorithm was limited to meshes built out of quads only, unlike this new implementation which supports all sort of polygons. That's a minor improvement that modelers will certainly appreciate.

[shingo]

I beg to differ GGA,

I am aware that Mental Ray has supported SDS for quite a while - via mental matter, which has not been adopted by any 3D application I can think of, but with respect to Maya, I could be wrong. So what you are telling me is that Maya is rendering subdivision surfaces (not poly mesh approx) via Mental Matter? OK fair enough.

Your statements appear contradictory. What does Reyes rendering have to do with tesselation? You just questioned why Avid have not ported their SDS algorithm to a geo shader, which implies that Alias themselves achieved this without a geo shader, am I correct?

It also makes sense this would be straightforward seeing as Maya’s subdivisiobn surfaces were limited to quads only. At the end fo the day, this point seems moot seeing as SDS in Maya never really took off and have remained unchanged since God knows when.

I assume you have used Prman or 3Delight, so you would know that there is no need for a geo shader to be created – it is simply a case of defining the object as a SDS. It is my understanding that Avid avoided going the geo shader route with MR because, there were limitations, inefficiencies and memory issues involved, not to mention that Avid's SDS supports triangles and n-gons.



Put it this way. Take a poly cube in Maya, triangulate it and render it as a sub-d without a) physically subdividing it or b) converting it to a Maya subdivision surface (which changes the topology and drops the attributed anyway). Does it work? With Catmul-Clarke, this would be straightforward would it not?

Having said that, I am prepared to stand corrected.

You are wrong, shingo. mental ray has supported subdivision surfaces as a primity type since v3.0 (3+ years ago). maya has shipped with the subd portion of mental matter since v5.0 and this gives you accurate tesselation of surfaces if you use a view approximation with a length of 1 or less, just like with nurbs or any reyes renderer.
XSI does not ship with this library and implements its own polygonal mesh subdivision that has always been catmull-clark compatible but not view dependant (why Avid never ported their code to a geometry shader and made it view-dependant is beyond me, really). Same with 3dmax.
The main difference is that mray's algorithm used in mental matter was not catmull-clark. It was a propietary algorithm that resulted in slightly different shape to catmull (a tad less smooth). This algorithm was a tad better than LW's metanurbs but a tad worse than Catmull. Most users will not really see the difference.
Also, mray's previous algorithm was limited to meshes built out of quads only, unlike this new implementation which supports all sort of polygons. That's a minor improvement that modelers will certainly appreciate.

[ThE_JacO]

You are wrong, shingo. mental ray has supported subdivision surfaces as a primity type since v3.0 (3+ years ago). maya has shipped with the subd portion of mental matter since v5.0 and this gives you accurate tesselation of surfaces if you use a view approximation with a length of 1 or less, just like with nurbs or any reyes renderer.
XSI does not ship with this library and implements its own polygonal mesh subdivision that has always been catmull-clark compatible but not view dependant (why Avid never ported their code to a geometry shader and made it view-dependant is beyond me, really). Same with 3dmax.
The main difference is that mray's algorithm used in mental matter was not catmull-clark. It was a propietary algorithm that resulted in slightly different shape to catmull (a tad less smooth). This algorithm was a tad better than LW's metanurbs but a tad worse than Catmull. Most users will not really see the difference.
Also, mray's previous algorithm was limited to meshes built out of quads only, unlike this new implementation which supports all sort of polygons. That's a minor improvement that modelers will certainly appreciate.


you are correct, but the main issues with mental matter are that:
1) it's slow
2) it only supports quads, no Npolys
3) it makes a HORRIBLE job of subdividing UVs (while 3delight and XSI make a pristine job of it)
4) the differences with CC are quite obvious, making the (normally near impossible) option of mixing it up with passes from a RMan engine even more unlikely then it normally is

Soft didn't introduce it because it's always been, in short, a waste of time.
I'm glad MI pulled their heads out of their arses and smelled some fresh air. Obviously the oxygen did them good and they decided to go for a standardized solution.

[shingo]

OK,

So let me get this staight.

Talking polys here, not Maya SDS. You are able to render a polygon object as a SDS in MR, but only if that object is made up exclusively of quads. Is that correct?

you are correct, but the main issues with mental matter are that:
1) it's slow
2) it only supports quads, no Npolys
3) it makes a HORRIBLE job of subdividing UVs (while 3delight and XSI make a pristine job of it)
4) the differences with CC are quite obvious, making the (normally near impossible) option of mixing it up with passes from a RMan engine even more unlikely then it normally is

Soft didn't introduce it because it's always been, in short, a waste of time.
I'm glad MI pulled their heads out of their arses and smelled some fresh air. Obviously the oxygen did them good and they decided to go for a standardized solution.

[CIM]

Lets hope Autodesk/Alias integrates these new features in Maya 8.0 and doesn't just tack them on.

[ThE_JacO]

OK,

So let me get this staight.

Talking polys here, not Maya SDS. You are able to render a polygon object as a SDS in MR, but only if that object is made up exclusively of quads. Is that correct?

pretty much, yes.
if I remember well, in theory it supports triangles as well, but the UVs interpolation algorithmical solution turns from bad to atrocious in that case, and don't get me started on how bad UV singularities are dealt with.

CC on the other hand is a great solution that is tolerant, and if well implemented deals with UVs too, of any connectivity scheme you throw at it.

[gga]

you are correct, but the main issues with mental matter are that:
1) it's slow
2) it only supports quads, no Npolys
3) it makes a HORRIBLE job of subdividing UVs (while 3delight and XSI make a pristine job of it)
4) the differences with CC are quite obvious, making the (normally near impossible) option of mixing it up with passes from a RMan engine even more unlikely then it normally is


1) is wrong. Its performance is very good.
2) is right.
3) is right, but only if you stick to linear uv interpolation (mayatomr's default). Use "texture space [subdivision]" to do proper uv interpolation following the subdivision rules.
4) is right, but it is relatively easy to work around that with a CC geometry shader or by using loop subdivision instead.


Talking polys here, not Maya SDS. You are able to render a polygon object as a SDS in MR, but only if that object is made up exclusively of quads. Is that correct?

Yes.
You can also render subds using all triangles, but then you will render using the Loop algorithm. Loop is overall a better algorithm than Catmull-Clark (*much* smoother surfaces), but due to working only with triangles it requires the software in your pipeline to be consistent on their triangulations -- or for you to work all in triangles, which is no good for most modeling packages. As subd goes, I recommend throwing CC down the trash and switching to a loop only or, alternatively, a hybrid algorithm (see: http://www.cs.rice.edu/~sschaefe/research/triquad.pdf).
If you are mixing with prman, prman also supports Loop since 12.xx something, albeit since prman is mainly a renderer that works with quads only, Loop is certainly more inefficient there.
I have not evaluated mray's new algorithm, but I'd be extremely disappointed if it was CC only. That would be a step backwards. My guess is that it is a hybrid.

[Droolz]

Sounds good, but turtle's been able to do this since at least version 2 - for people wondering why it matters it's an increadibly efficeint way of working [IMHO], in that your only ever dealing with low poly cages within your 3d package, making the scenes very lightweight and easy to deal with.

[gtbannas]

Did you guys really read the press release.
1. Its pretty fast
2. 3.5 addresses the subd's with .... well read for yourself
Catmull-Clark polygon meshes ("ccmeshes") have been introduced. This subdivision surface type uses Catmull-Clark rules for smoothening and supports polygons with arbitrary numbers of vertices.

3. can't speak on
4. can't speak on.

[ThE_JacO]

Did you guys really read the press release.
1. Its pretty fast
2. 3.5 addresses the subd's with .... well read for yourself
Catmull-Clark polygon meshes ("ccmeshes") have been introduced. This subdivision surface type uses Catmull-Clark rules for smoothening and supports polygons with arbitrary numbers of vertices.

3. can't speak on
4. can't speak on.


and did you read the actual posts?
nobody was whinging about the problems, and pretty much everybody seems to know fairly well what addresses what.

as for mental matter being pretty fast, I'd still disagree, but maybe something changed over the last 14 months (although nothing I'm aware of), which was the last time I tryied to use them, before deciding they really weren't worth the effort.

anyway... I'm actually quite excited by this release, they are plugging some of the holes the size of kansas they had for a long while. Just wish they could be saying more about mental mill and metaSL. Not much longer to wait anwyay.

[shingo]

Love the flag BTW Jaco. ;-)

and did you read the actual posts?
nobody was whinging about the problems, and pretty much everybody seems to know fairly well what addresses what.

as for mental matter being pretty fast, I'd still disagree, but maybe something changed over the last 14 months (although nothing I'm aware of), which was the last time I tryied to use them, before deciding they really weren't worth the effort.

anyway... I'm actually quite excited by this release, they are plugging some of the holes the size of kansas they had for a long while. Just wish they could be saying more about mental mill and metaSL. Not much longer to wait anwyay.

[Mauritius]

3) is right, but only if you stick to linear uv interpolation (mayatomr's default). Use "texture space [subdivision]" to do proper uv interpolation following the subdivision rules.

I wouldn't be so sure about that. You know that to proper interpolation requires more than just applying the subdivision rules to Us and Vs. You need actually need to look at the data as a pairt, so you can detect corners and borders in the UV atlas and do the right thing(tm). Few renderers get all cases right. I would be surprised if mray was among them given by how few people the old feature was used due to being sold as a separate package and given how new the new full implementation is.
And when you talk about arbitrary data like points, 4 by 4 matrices or n-dimensional arrays the problem becomes increasingly complex. As if you just interpolate each component individually using the subdivision rules, the result is only what you expect if your data is continous accross faces of the control polyhedron. In all other cases it will give you wrong result w/o having a reul set to deal with all the corner and edge cases.
Finally, detecting continuity is another problem in itself that renderers should better be able to solve on-the-fly these days, as packages like XSI and Maya tend to **** up UVs by introducing slight inaccuracies accross per face per vertex data that generate dicontinuities.


You can also render subds using all triangles, but then you will render using the Loop algorithm. Loop is overall a better algorithm than Catmull-Clark (*much* smoother surfaces),

I disagree since that entirely depends what you need to do. CC are a generalization of cubic b-spline meshes to many topologies the former type can not represent at all or not represent well. If you look at the literature, source code and software available to deal with cubic b-spline meshes and consider the fact that you can convert most CC subdivs into a set of cubic b-spline patches, "better algorithm" becomes a matter of application context. Loop also has certain other mathematial disadvantages that one might not care about when uisng them to model a character, a piece of cloth or an ocean surface but which can become an issue for for applications like hard surface modeling.
I frankly can't understand what makes people come up with such generalizations as yours.


If you are mixing with prman, prman also supports Loop since 12.xx something, albeit since prman is mainly a renderer that works with quads only, Loop is certainly more inefficient there.

PRMan and 3Delight also support a mix between Loop and CC. Howbeit, this breakes continuity on subdivs that are composed of several pieces. Which is a perfect example why, again, you can't generalize on one scheme or even a mix being a better choice than the other -- all depends on what your application example is.


I have not evaluated mray's new algorithm, but I'd be extremely disappointed if it was CC only. That would be a step backwards. My guess is that it is a hybrid.
I bet most mray users will be pleasantly surprised in any case to have some "roughly-since-a-decade-state-of-the-art-higher-order-surfaces" in this 'high-end' renderer in 2006 finally at all. ;)

Cheers,

Moritz

[gga]

I wouldn't be so sure about that. You know that to proper interpolation requires more than just applying the subdivision rules to Us and Vs. You need actually need to look at the data as a pairt, so you can detect corners and borders in the UV atlas and do the right thing(tm).

Yes. That in itself is a very simple problem. Doing the right thing(tm) has been done by many people in this industry.

And when you talk about arbitrary data like points, 4 by 4 matrices or n-dimensional arrays the problem becomes increasingly complex.

Point data should be easy. It is dealt exactly like points in 3d space.
Matrix and array data attached to vertices of a subd, afaik, are not supported by any renderer as of yet. Well, with a renderer with a C api like mray you can already support them (with a lot of coding), albeit I would wonder what the actual use of that would be.

I disagree since that entirely depends what you need to do. CC are a generalization of cubic b-spline meshes to many topologies the former type can not represent at all or not represent well.

True, CC is a generalization of degree 3 b-spline patches.
But you are wrong about your second statement. Loop is a generalization of degree-4 b-spline *triangular* patches (or degree 4 box splines). Just as a triangle can represent anything a square can and a nurbs of degree 4 can represent anything than a nurbs of degree 3 can, it follows that Loop can represent anything CC can. You'll just be dealing with an additional "row" of vertices.

If you look at the literature, source code and software available to deal with cubic b-spline meshes and consider the fact that you can convert most CC subdivs into a set of cubic b-spline patches, "better algorithm" becomes a matter of application context.

No, better algorithm taken in the context the phrase was in, referred to that of smoothness. If you agree that a degree 4 surface is smoother than a degree 3 surface, you'd have to agree my statement was fair. And if you don't agree, no sense in discussing mathematical disadvantages of loop :)
BTW, just as you convert a CC into a bspline, you can convert a Loop subd into a triangular bspline patch.
Other benefits to Loop included being, as far as I know, free of patents. Well, kind of... see below.:sad: Perhaps it is time to move to the sqrt() schemes after all...

PRMan and 3Delight also support a mix between Loop and CC. Howbeit, this breakes continuity on subdivs that are composed of several pieces.

I have not tried their recent subds in either, but could you post an image of what you mean? I honestly don't follow. What you describe seems like a bug to me.
The whole idea behind a hybrid subdivision algorithm is that you get proper continuity among the joint areas. That is, catmull-clark (and another scheme like loop) live side by side in the same subd.
Besides the paper I mentioned, the state-of-the-art in hybrid catmull-clark comes from Loop, who, for the first time, manages to obtain C2 continuity everywhere, even at extraordinary vertices. See: http://research.microsoft.com/~cloop/LoopCS2002.pdf (http://research.microsoft.com/%7Ecloop/LoopCS2002.pdf)
The paper made it to the web afaik in 2006, it is dated to be from 2002 and Loop's web page lists it as having been presented in France in 2004... hopefully noone is trying to place a patent on that. *sigh, maybe yes* Loop under Microsoft this month has proposed a patent for some obvious thing like modifying Stolfi's quadedge operators to triangles. How was it you go about contesting an obvious patent in the US? (http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=1&p=1&f=G&l=50&d=PG01&S1=loop.IN.&OS=in/loop&RS=IN/loop)
Anyway, back on topic... If you model surfaces as several pieces or as a non-manifold in prman, their algorithm used to break (at least up to prman11, not sure about RIHierarchicalSubdivisionMesh). It is up to your converter to notice that and spit each piece separately and use their "stitch" extension.
My bet is that that will become a huge headache for rib renders once you try to introduce IPR into it and people try modeling or surfacing subds with IPR active :)
Mray also has problems with non-manifold subds, but a subd made out of several pieces works fine.


I frankly can't understand what makes people come up with such generalizations as yours.
Which is a perfect example why, again, you can't generalize on one scheme

I'm not sure I follow you here either. The renderers you tend to prefer (and speak highly of) *chose* to implement and support a hybrid subdivision. I, who actually tend to favor mental ray, also state that that is a better algorithm than just CC.
It may indeed be a generalization, but it is probably a generalization several, usually dissenting, researchers do agree upon.

Loop also has certain other mathematial disadvantages

What are these mathematical disadvantages?
I can think of several *practical* disadvantages in production -- all of them easily solvable, imo... but not mathematical ones.

[StefanA]

Jaco... stop talking about XSI and 3delight.... or release your XSI_to_3Dlight plugin :)

sorry for the [OT] response

/stefan

[ThE_JacO]

Jaco... stop talking about XSI and 3delight.... or release your XSI_to_3Dlight plugin :)

sorry for the [OT] response

/stefan

it's not mine, but another person participating to this thread wrote singlehandedly the whole core and interface of it.

you're barking up the wrong australian tree dude :p

[Mauritius]

Yes. That in itself is a very simple problem. Doing the right thing(tm) has been done by many people in this industry.
I think you don't understand the problem I'm talking about. You have to look at data as tuples. How do you interpolate when you have such a tuple on a t-junction e.g.? It is all but trivial and you have to make certain assumptions about the [most] typical use cases in you algorithms or expose an rather large array of options to steer case-by-case component interpolation [per object or even per piece].
It took some very skilled renderer developers I happen to know six months to get the thing right and that included constant feedback with use-cases and production scenes. That's why I doubt mray's current (or new) implementation is anywhere ready for prime time.
Point data should be easy. It is dealt exactly like points in 3d space.
No, I'm talking about-per-vertex-per-face data like UVs! Not per vertex data. Yes, per vertex is totally trivial. But per-vertex-per-face (aka facevarying/facevertex in RenderMan) is not at all trivial. And as I said, it becomes increasingly non-trivial with the per-vertex tuples having higher dimensionality.
Matrix and array data attached to vertices of a subd, afaik, are not supported by any renderer as of yet. Well, with a renderer with a C api like mray you can already support them (with a lot of coding), albeit I would wonder what the actual use of that would be.
You are mistaken. All that is supported by most RMan compliant renderers. It is definitely for PRMan and 3Delight and I seriously doubt AIR and RenderDotC don't support it. For the OSS ones, you'd have to check.
And it is one of the many reasons why anyone who knows both the mray and the RMan API inside out perceives the latter still as vastly superior (and cleaner, but that is OT).
And for uses-cases, just of the top of my head, think of defining a 4x4 space per-vertex-per-face for carrying out displacement in.
But you are wrong about your second statement. Loop is a generalization of degree-4 b-spline *triangular* patches (or degree 4 box splines). Just as a triangle can represent anything a square can and a nurbs of degree 4 can represent anything than a nurbs of degree 3 can, it follows that Loop can represent anything CC can. You'll just be dealing with an additional "row" of vertices.
You missed my point. My point was not about which is the better choice as in "smoother" but which is the better choice to rely on in production.
BTW, just as you convert a CC into a bspline, you can convert a Loop subd into a triangular bspline patch.
And how many 3D packages and renderers out there deal well or at all with triangular patches? Do a search for source code on this. This is all well and fine in theory, but in crude production reality the availability of tools that support a certain geometry type matter more. Most packages represent triangular patches as degenerate quad patches with a singularity in one corner. I personally don't want to go there until I have tools and algorithms readily at hand to deal with this properly.
I have not tried their recent subds in either, but could you post an image of what you mean? I honestly don't follow. What you describe seems like a bug to me.
It is a rather old flag (4+ years, I think) that basically says "if you encounter a triangle on a CC sds, switch the scheme to something else (Loop?)". My guess would be that this got implemented rather quickly and just linearly blends between the results of both schemes around the area in question. And this breakes continuity if you model with subdivision sub patches and the area in question is close to an edge. I can think of a way to overcome this, by exporting another two rows of faces around the area and tagging those as "holes". Anyway, that is neither efficient nor very elegant.
The whole idea behind a hybrid subdivision algorithm is that you get proper continuity among the joint areas. That is, catmull-clark (and another scheme like loop) live side by side in the same subd.
You get it mostly, but I talk about sds that are split into several primitives (that don't 'know' about each other). The hybrid scheme must deal with all configurations of faces in the same way. As soon as the scheme contains rules like "if a triangle adjacent to a n-gon (n>3) do this instead of that" it breaks on edge cases where the adjacent geometry is missing/not known (aka it lives on a the next primitive). To deal with that you need to make primitives 'know' about each other. This then requires stitching etc. which makes for an interface of dubious elegance. And elegance translates to ease of use translates to turnaround time for writing tools to support it in production.
Anything is possible. Whether anything is also desirable from a VFX application perspective is another question. If you talk of markets like CAD and design of course, the pov is an entirely different one and I agree with most of what you said. ;)
Anyway, back on topic... If you model surfaces as several pieces or as a non-manifold in prman, their algorithm used to break (at least up to prman11, not sure about RIHierarchicalSubdivisionMesh).
CC subdivision on non-manifold toplogies is not defined and rightfully so. People that model this sort of geometry should be banned from working in VFX. :) It's the scheme that breaks, not the algorithm. And if you split the surface into manifold pieces, it works fine, as one would expect. The problem remains how do you split at an edge that has more than two faces connected, or if you wanted to support interpolation of this, how to come up with a case that gives the user what they expect under all circumstances? Either a crease at that edge or something very hard to control/predict, as only two faces can be used for smooth interpolation, otherwise you end up with a volume, not a surface anymore.
It is up to your converter to notice that and spit each piece separately and use their "stitch" extension.
The stitch extension is not about pulling seams together but to prevent displacement cracking afaik. Ensuring continuity accross split sds pices of any kind in the first place is up to the user of the RMan API.
My bet is that that will become a huge headache for rib renders once you try to introduce IPR into it and people try modeling or surfacing subds with IPR active
You don't need to use RIB. You can send data directly to the renderer. Few people know this. It is fully supported in 3Delight and RenderDotC by issuing an RiBegin(NULL) and you can hack around it in PRMan by making clever use of DSOs. The other problems you refer to are more about data storage and less about IPR or sds in general. To properly do IPR, you need to store per-pixel fragment lists. All fine even for more complex scenes until you stop doing occlusion culling to support opacity changes or use curves (hair, fur, grass etc.) -- not to even talk about moving geometry around or deleting/creating it.
Mray also has problems with non-manifold subds, but a subd made out of several pieces works fine.
As they do in PRMan, 3Delight & co.
What are these mathematical disadvantages?Disadvantages as in "harder math" for a TD. There's just less literature to draw from when you are talking anything that is based on triangular patches.


Beers,

Moritz

[Lorecanth]

great discussion thanks guys.

[ThirdEye]

great discussion thanks guys.

Indeed, if only i could understand what that stuff means :D

[levork]

Very interesting thread. A few specific PRMan points:


Anyway, back on topic... If you model surfaces as several pieces or as a non-manifold in prman, their algorithm used to break (at least up to prman11, not sure about RIHierarchicalSubdivisionMesh). It is up to your converter to notice that and spit each piece separately and use their "stitch" extension.


Completely disjoint meshes were supported starting in PRMan 12, but as Moritz mentioned, this generally isn't why stitching is necessary. Non-manifold meshes mostly still aren't supported. There are some limited cases where more than two faces that meet at a single edge are detected and split apart, but generally supplying a non-manifold mesh is asking for trouble.


If you are mixing with prman, prman also supports Loop since 12.xx something, albeit since prman is mainly a renderer that works with quads only, Loop is certainly more inefficient there.


PRMan now supports triangles throughout the entire algorithm. Loops aren't turned into degenerate quads, they're proper triangles. They're very efficient, and in any event much better for rendering a triangular mesh than using the Catmull-Clark scheme, which has to turn each triangle into 3 quads up front.


PRMan and 3Delight also support a mix between Loop and CC. Howbeit, this breakes continuity on subdivs that are composed of several pieces.


PRMan had a bug with this scheme a long time ago, but it was also fixed way back when. This was in the CC scheme: it simply used a modified rule to deal with top level triangles. I'm not aware of any continuity issues with the current code, although with Loop support now this tends to be less of an issue anyways.

On another point: it's probably easier to think of Loops as generalizing to a quartic triangular bezier patch, not a quartic triangular b-spline patch, since the conversion from box-spline to bezier is well defined and the resulting prim is more efficient.

[yann22]

Indeed, if only i could understand what that stuff means :D

thx, for a moment I had this 'everybody else seems to be a genius why was I born so stupid'
feeling creeping up on me :)

[mech7]

thx, for a moment I had this 'everybody else seems to be a genius why was I born so stupid'
feeling creeping up on me :)

Your not the only one :shrug:

[gga]

I think you don't understand the problem I'm talking about. You have to look at data as tuples. How do you interpolate when you have such a tuple on a t-junction e.g.? No, I'm talking about-per-vertex-per-face data like UVs! Not per vertex data. Yes, per vertex is totally trivial. But per-vertex-per-face (aka facevarying/facevertex in RenderMan) is not at all trivial. And as I said, it becomes increasingly non-trivial with the per-vertex tuples having higher dimensionality.

No, I understood perfectly. You'll be surprised but there *are* people outside the renderman community that have also been doing subdivision surfaces even before Pixar's 1997 or so paper. After all, Catmull's original paper is from 1978 and Loop is from 198x.
The way you interpolate a t-junction is you follow the subd rules (usually this means interpolating either linearly in the face or looking at surrounding faces and following the cc/loop scheme).

It took some very skilled renderer developers I happen to know six months to get the thing right and that included constant feedback with use-cases and production scenes.

That may be, but it was not because of that problem. The problem you mention is really trivial to solve. It took me 2 weeks to address it the second time I wrote subd code.
What's really hard for subds in a render engine is getting some form of adaptive subdivision working efficiently. That can indeed take months.

That's why I doubt mray's current (or new) implementation is anywhere ready for prime time.

I cannot vouch for the new one, but the old one was definitively ready for primetime. Has been for 2 or so years at least.

And it is one of the many reasons why anyone who knows both the mray and the RMan API inside out perceives the latter still as vastly superior (and cleaner, but that is OT).

No, that's just a generalization. You just assume I don't know both apis inside out. I do.
And my preference is the opposite as yours, both in terms of api and cleaner.
What most people admire about Prman is not so much the spec, quite honestly, but its rendering core.
The mental ray api is generally much better thought out and also cleaner as a scene description for geometry creation, ipr, render passes, shadow mapping, light/shadow linking, avoiding having to map the renderer to a certain hardware and for adding new primitive types the renderer does not support natively.
The RISpec as a scene description has going for it that it allows user defined attributes to be passed onto your shader in a very clean way. It can also be more compact but only if you take shadow maps out of the equation.
As a shading api, the renderman shading language is still one in its class. The only real big flaw in it is that it was never thought with shading networks in mind (the idea being, the language itself IS your shading network). On the other hand, mray's phenomena allows you to take advantage of hardware acceleration of shaders today, and not sometime in the future.

And how many 3D packages and renderers out there deal well or at all with triangular patches?

Renderers, two at least (prman and mental ray) through their Loop scheme. 3D packages, none I am aware as of yet.
There is however one real practical production reason why I do advocate a triangle scheme over CC, which has little to do with its smoothness, thou.

It is a rather old flag (4+ years, I think) that basically says "if you encounter a triangle on a CC sds, switch the scheme to something else (Loop?).

No, that's not Loop at all.

You get it mostly, but I talk about sds that are split into several primitives (that don't 'know' about each other).

I thought you did. The whole point of subds is that you don't model in pieces anymore. Yet, I understand why you might want that. Personally, I don't think stitching like that belongs to a 3d renderer and, yes, I do have two solutions for that already... at least if I am right about what I think the reason is for you asking that.

CC subdivision on non-manifold toplogies is not defined and rightfully so.

No, not really. Non-manifold edges should be dealt as hard edges and not fail, either thru the converter or the renderer itself. During animation and rendering, you shouldn't have any non-manifold edges, for sure. During modeling, some operations might inadvertedly lead to them, thou. Having non-manifold edges not fail becomes useful for ipr, mainly.

The stitch extension is not about pulling seams together but to prevent displacement cracking afaik. Ensuring continuity accross split sds pices of any kind in the first place is up to the user of the RMan API.

Oh, yes. You are right. I think this is now superceded with the new subd algorithm of prman12+ and their new Hierarchical subds.

You don't need to use RIB. You can send data directly to the renderer. Few people know this.

It is actually very well known. Problem is, after you do that you are still stuck with a stack-based geometry api, and that's a big issue for IPR (at least until you map your whole api to a chip like opengl does) and, unless you can think of some new method of doing things, fixing that in RISpec will probably involve copying the mray object-instance paradigm in some shape or form. Using DSOs or abusing of read archives is not helpful.
You know this since you were extending instancing in the 3delight api into something that was closer to mray.
Since I am not interested in locking myself to any hardware just yet and the mental ray api already has this thought out much better and has had this working since v2.1 in the 90s, I still state the scene api in mental ray is much better thought out.

To properly do IPR, you need to store per-pixel fragment lists. All fine even for more complex scenes until you stop doing occlusion culling to support opacity changes or use curves (hair, fur, grass etc.) -- not to even talk about moving geometry around or deleting/creating it.

All stuff that mray already supports. As Thomas once mentioned to me with some sorrow "you end up writing not a renderer but a database". Translation: lots of hard to write, hard to debug code that you know noone will truly appreciate.
The challenge of this for mray now is just making it work painlessly at 4K.

PS. The one feature in 3.5 that I *am* truly looking forward to is their light and shadow linking mechanism.

[wurp]

what is this light linking, is it the same as inclusive/exclusive lights?


PS. The one feature in 3.5 that I *am* truly looking forward to is their light and shadow linking mechanism.

[shingo]

Gonzalo,

Does shadow linking allow for shadow maps to be baked and if not, is there anything new in 3.5 that will allow this to be done?

PS. The one feature in 3.5 that I *am* truly looking forward to is their light and shadow linking mechanism.

[gga]

what is this light linking, is it the same as inclusive/exclusive lights?

Assuming you come from an xsi/softimage background, yes. The shadow linking would allow a similar feature to inclusive lights but for the purpose of indicating whether some objects cast shadows under certain lights.
All 3d vendors support light linking of some sort for mray, but it is done in an incompatible (and inefficient) way. Don't worry if the following explanation goes over your head...

3dmax/Softimage/XSI, for example, IIRC, use light lights in shaders through a special light parameter while maya supports that also but for maya materials it uses a special shader. This makes custom shaders usually not support light linking smoothly across 3d packages.
Having light linking as the shader parameter means respitting all the shader parameters for each object that has different light links, and evaluating all those lights on each shader invocation, which is silly (albeit it can also have its uses).
The main benefits of unifying this in the instance is that it allows handling light linking much more smoothly in large scenes, ipr and across file objects.

Ideally, if lights are propagated down instance groups, a smart converter in pseudo mi format could then write an .mi file like:


light "lgtShape"
end

instance "lgt1" "lgtShape"
end

object "A"
end

instance "Ainst" "A"
end

object "B"
end

instance "Binst" "B"
end

instgroup "Group1"
"Binst" "Ainst"
end

instance "LightGroup" "Group1"
shadow lights "lgt1"
end


And "lgt1" would then be casting shadows ONLY for objects Ainst and Binst. During IPR, if light linking changes for that light, you just re-spit "Group1" and the renderer would re-render those two objects only.
If lights and shadows are propagated down the instance and instance groups as I show here (not sure if that feature is in 3.5) you would then get the one and only benefit of the RIB stack, but without its headaches.

[gga]

Does shadow linking allow for shadow maps to be baked and if not, is there anything new in 3.5 that will allow this to be done?

What package are you using? mray has supported saving shadow maps to disk since v3.
Under maya at least, the GUI of the lights already support a shadow map filename to save the shadow map to disk and the rebuildShadowMap setting in the render globals controls whether shadow maps are re-generated on each render or are just read from disk.
Or do you mean something entirely different by baking shadow maps?

[shingo]

Gonzalo,

I am using XSI and there doesn't appear to be such an option. There is an option to rebuild shadow maps, and OGL accelerting them, but no optiuon to name them.

So in MR (as of v3) you can pre-compute shadow maps is that correct, so that they don't have to be regenerated when re-rendering?

What package are you using? mray has supported saving shadow maps to disk since v3.
Under maya at least, the GUI of the lights already support a shadow map filename to save the shadow map to disk and the rebuildShadowMap setting in the render globals controls whether shadow maps are re-generated on each render or are just read from disk.
Or do you mean something entirely different by baking shadow maps?

[urgaffel]

I don't know if you can pre-compute them but when you use the Shadow map cache, they are computed once (1st frame of animation/still frame), saved to the harddrive and then mr reads the cache instead of calculating the shadow maps for every frame/re-render. At least that's how I've understood it.

One thing I've had problems with though is to get high quality shadow maps, they seem to be jaggy and jittery no matter what I do. Any suggestions why? (besides me being an idiot I mean ;))

[Saturn]

It doesn't seam to be wired in XSI. Nasty bug ?
But yes that the idea generate the shadows to not get it recalculated on your different pass.

[Mauritius]

No, I understood perfectly. You'll be surprised but there *are* people outside the renderman community that have also been doing subdivision surfaces even before Pixar's 1997 or so paper. After all, Catmull's original paper is from 1978 and Loop is from 198x.
Hmm, that's why mray gets sds support now. And don't answer with mental matter. Too few users to be production ready for VFX plus has the shortcomings other people mentioned before. Other than that I'm well aware of stuff happening around sds. I was suprised it took Pixar so long to see the light with all the subdivision schemes already implemenbted as operators or commands for polygon modeling in other 3d programs (Max) or for rendering (Lighwave's MetaNURBs).
The way you interpolate a t-junction is you follow the subd rules (usually this means interpolating either linearly in the face or looking at surrounding faces and following the cc/loop scheme).
You still didn't get my point. I'm talking about the difference of interpolating a tuple of arbitrary dimensions vs. single data. Aka interpolating uv[2] vs. interpolating u, then v, in all three cases using a case-sensitive (e.g. considering borders etc.) version of the resp. subdivison scheme. If you interpolate u and v separately (aka the algorithm does not 'know' that they belong together somehow), in case of noted t-junction, the results are completely different for uv[2] vs u, then v interpolation. And for uservar_abcd[4], the results are different from interpolating uservar_a, userva_b, uservar_c and finally uservar_d all seperately.
Speaking about 'trivial'. Any problem seems trivial once you understood it fully. Being sure about the latter can be non-trivial too, if you get my point. And so I wonder if it took you still just two weeks (assuming for a second I was wrong and you understand the difference in interpolating a tuple vs. interpolating a single variable on a CC sds). Then how long did it take you the first time and was that a production-proof solution?
No, that's just a generalization. You just assume I don't know both apis inside out. I do.
I can deduce about your knowledge of the RI API from your previous posts that you indeed do not know it inside out. You seem to know the RI more well than the average TD, I give you that, but stating that RIB files are binary is bollocks. Also, RIBs, while supporting a hierarchical attribute state don't force you to use that (I particularly refer to the "prman 11 or mentel ray 1.5" thread). And lastly, there's no need to use RIBs at all, you can send data directly to the renderer in many implementations using a RiBegin(NULL).
And my preference is the opposite as yours, both in terms of api and cleaner.Because you don't know the RI well enough and you haven't used it enough in production in different pipelines. My bold guess is that your main exposure has been during your days at ILM in whatever pipeline they had at that time. ;)
What most people admire about Prman is not so much the spec, quite honestly, but its rendering core.I personally care as much about the implementation as I care about the API. If the Gelato guys had come up with st. that really kicked the RI spec's ass, I'd probably have taken the time to write a Pyg/GSL to RI/SL binding. Same with mray. But it's API sucks balls the size of planets imho. And it is just a nightmare when it comes to stability and any features that are slightly new. You simply can't use them. And the whole renderer screams "we added stuff on demand without taking the required time first to sit down and think about a good API". Again, that's just my pov and I'm just stating it here as a 2nd opinion since other people read this thread.
I respect that you have a different pov.
The mental ray api is generally much better thought out and also cleaner as a scene description for geometry creation, ipr, render passes, shadow mapping, light/shadow linking, avoiding having to map the renderer to a certain hardware and for adding new primitive types the renderer does not support natively.
I never heard that before. Could you state in which way the mray's API is better at describing any of these tasks?
The RISpec as a scene description has going for it that it allows user defined attributes to be passed onto your shader in a very clean way. It can also be more compact but only if you take shadow maps out of the equation.
Why is that? You can make your "world" an inline archive, describe all maps (textures, shaow-, environment-, photon maps, etc. etc.) in one RIB and that spits out this data, then renders it. The RI spec also easily allows for a particular implementation to use handles instead of filenames, so the whole thing can happen solely in memory. This statement of yours again seems to indicate that you overestimate your own knowledge about the RI a little bit (which is more that a scene description as it encompasses SL and you can use shaders in other contexts that rendering to start with). ;)
As a shading api, the renderman shading language is still one in its class. The only real big flaw in it is that it was never thought with shading networks in mind (the idea being, the language itself IS your shading network).
That's not such a flaw, look at the solution the Gelato guys came up with. Their API might be debatable, but the possibility is there by plain allowing to link any parameter of a shader with any output class parameter of any other shader. Similarly implemented in the RMan compliant Aqsis renderer with a new RI call btw.
This is a choice of abstraction level and not a limitation of the API. You can use a shader tree building tool like Houdini, Slim or ShaderMan to build your trees, then generate a very optimized shader from that. I agree that it is nice to have an API that allows this sometimes, but in general it is not a shortcoming to not have it. Besides, the RI spec makes explicit reference to Cook's famous "Shade Trees" paper, so the authors were well aware of their choice -- it was an intentional one.
But talking of flaws, the big problem is the lack of strctured user data (structs). However, once these get implemented (and they will), that opens another can of worms to pollute the clean primtive variable API or the RI as how does one deal with structs that contain data of different detail. The reason being of course that people will likely want to be able to attach structured data to primtives like they do with primitive variables.
On the other hand, mray's phenomena allows you to take advantage of hardware acceleration of shaders today, and not sometime in the future.
Hardware acceleration meaning what? That you cannot gurantee that your image looks the same anymore when you swap the GPU? You have to understand the goals of each API. And you could easily write DSO shadeops using hardware acceleration for SL (see this SIGGRAPH's RMan course).
Renderers, two at least (prman and mental ray) through their Loop scheme. 3D packages, none I am aware as of yet.
My point exactly. As you always need to do stuff with geometry inmproduction before rendering. With CC I'm sure I can convert that into a net of connected b-spline patches then do fancy stuff with that before I render. With a Loop sds, I currently can't.
No, that's not Loop at all.
How can you know that they don't just triangluate any polygons adjacent to any triangle, use Loop on that subnet, then lineraly blend with the result of CC? Do you have PRMan source code at hand??? ;)
No, not really. Non-manifold edges should be dealt as hard edges and not fail, either thru the converter or the renderer itself. During animation and rendering, you shouldn't have any non-manifold edges, for sure. During modeling, some operations might inadvertedly lead to them, thou. Having non-manifold edges not fail becomes useful for ipr, mainly.
Why hard? How do you reason this? Different users may want completely different things to happen in such a situation. PRMan & 3Delight deal quite well with non-manifold sds. They bitch about it and try to their best to render st. "useful". Howbeit, "useful" is a foggy term at best in such a context. "hard edges" = "right" I'd call biased at best. ;)
It is actually very well known. Problem is, after you do that you are still stuck with a stack-based geometry api, and that's a big issue for IPR (at least until you map your whole api to a chip like opengl does) and, unless you can think of some new method of doing things, fixing that in RISpec will probably involve copying the mray object-instance paradigm in some shape or form. Using DSOs or abusing of read archives is not helpful.
Inline archives (that allow a true 'object instances') exist since years in the RI. What are you talking about? You can create an entire attribute state inside an inline archive and instance that. Thr spec is not clear what happens if an inline archive handle gets redefined but a sensitive thing would probably be to overwrite. From that pov, the RI is largely IPR ready since years.
And speaking just of attributes -- you can name "resources" and instance them since PRMan 12. This was overdue but there were straightforward ways around this before. The fact that I've never seen a pipeline taking advantage of them doesn't mean they didn't (and still do) exist.
Interestingly, my XSI to 3Delight exporter starts rendering an average complex scene much quicker than does XSI with mray even though they have shared memory scene database. I find t intersting that features people deem so important in some contexts (IPR) actually aren't at all when one looks at the real world(tm).
You know this since you were extending instancing in the 3delight api into something that was closer to mray.
Yes, but if you used RIB stream processing (e.g. with good old sed), you could do this before. The fact that an API supports hierarchy doesn't mean it only works when used that way.
Since I am not interested in locking myself to any hardware just yet and the mental ray api already has this thought out much better and has had this working since v2.1 in the 90s, I still state the scene api in mental ray is much better thought out."Much better" as "in no guarenteed mapping of any feature the resp. author of the shader for one particular architecture chose to implement"? I totally disagree.

Cheers,

Moritz

[urgaffel]

With the risk of sounding silly, what is IPR?

[BillSpradlin]

IPR=Interactive Photorealistic Rendering. A feature that allows you to tweak shader/light settings in a somewhat fast and interactive way (depending on the implementation you are using). I used to use it quite a bit in my earlier days, but don't use it at all anymore.

Answering a question in this thread must mean Armegeddon and the Apocolypse will follow shortly.

I'm extremely happy when two very knowledgeable people debate things such as this, my brain is like a sponge over here, soaking up all the goodness =)

[ThE_JacO]

the thread has gone wildly off topic, but seing the ritz (mauritius, estimated arguer and colleague of mine and fellow espresso addict :) ), and gga (for whom I've had only the utmost respect since I first read his posts years ago) panning this out is making for an OT that's, funnily enough, largely more on the bullseye then 99.99999% of the threads around here.

I'm actually hoping it will rage on for a bit longer, and then at some point I'll post those pictures of Moritz covered in nutella from the wrap up party, just to make sure nobody takes him seriously ever again.

[rendermaniac]

I personally care as much about the implementation as I care about the API. If the Gelato guys had come up with st. that really kicked the RI spec's ass, I'd probably have taken the time to write a Pyg/GSL to RI/SL binding. Same with mray. But it's API sucks balls the size of planets imho. And it is just a nightmare when it comes to stability and any features that are slightly new. You simply can't use them. And the whole renderer screams "we added stuff on demand without taking the required time first to sit down and think about a good API". Again, that's just my pov and I'm just stating it here as a 2nd opinion since other people read this thread.
I respect that you have a different pov.


The Gelato spec looks pretty nice. The main thing stopping it's adoption is the hardware requirements. I think the stability is more an issue of the implementation isn't it? Or do you mean that the Gelato spec is constantly changing??

It's also not too disimilar to RenderMan. I suspect mainly for legal reasons - a bit like Houdini VEX.

The Mental Ray implementation is the reason I don't like it - it consumes far too much memory for a start. Plus motion blur etc. The raytracing engine gives smoother results than prman (don't know how it compares to 3delight). Plus it doesn't fit as neatly into our pipeline.


I never heard that before. Could you state in which way the mray's API is better at describing any of these tasks?

Why is that? You can make your "world" an inline archive, describe all maps (textures, shaow-, environment-, photon maps, etc. etc.) in one RIB and that spits out this data, then renders it. The RI spec also easily allows for a particular implementation to use handles instead of filenames, so the whole thing can happen solely in memory. This statement of yours again seems to indicate that you overestimate your own knowledge about the RI a little bit (which is more that a scene description as it encompasses SL and you can use shaders in other contexts that rendering to start with). ;)


You don't even need an archive - just have a multiframe RIB file with a call between the shadow and main render to make the shadow file.

Wasn't Gonzalo talking about including the actual shadow maps as part of the data? Can't mi files embed this somehow?

Is in memory shadow maps specific to 3delight? I have never heard of it before, but it sounds potentially quite useful.


That's not such a flaw, look at the solution the Gelato guys came up with. Their API might be debatable, but the possibility is there by plain allowing to link any parameter of a shader with any output class parameter of any other shader. Similarly implemented in the RMan compliant Aqsis renderer with a new RI call btw.


I know I am asking for trouble for saying this, but didn't you just say the Gelato API "sucks balls" ;)


This is a choice of abstraction level and not a limitation of the API. You can use a shader tree building tool like Houdini, Slim or ShaderMan to build your trees, then generate a very optimized shader from that. I agree that it is nice to have an API that allows this sometimes, but in general it is not a shortcoming to not have it. Besides, the RI spec makes explicit reference to Cook's famous "Shade Trees" paper, so the authors were well aware of their choice -- it was an intentional one.


I'm sorry but this is a limitation of the API. Gelato and Aqsis get around this by using renderer specific extensions. They are not part of the RI spec.

Personally I think phenomena are a good way of building shaders. They are all compiled so they are much stabler, and it is much easier to make and break connections at runtime. This could give more IPR like results. It also lets you do tricks with the .mi file to change stuff.

Personally I find runtime control a lot more useful than compile time.


But talking of flaws, the big problem is the lack of strctured user data (structs). However, once these get implemented (and they will), that opens another can of worms to pollute the clean primtive variable API or the RI as how does one deal with structs that contain data of different detail. The reason being of course that people will likely want to be able to attach structured data to primtives like they do with primitive variables.


I agree that this is something that needs addressing.

Ironically I think Mental Ray handles this quite nicely ;) I think there is a state object which holds all the global variables (haven't really used it enough to say).


Hardware acceleration meaning what? That you cannot gurantee that your image looks the same anymore when you swap the GPU? You have to understand the goals of each API. And you could easily write DSO shadeops using hardware acceleration for SL (see this SIGGRAPH's RMan course).


Could you point out where this is? I didn't see any mention of calling GPU code from a DSO within a shader.

I have heard rumours that Hal Bertram has done this before - I would love to see some example code - but his interaction stuff was for speeding up fully software renders.

I think the new SIMD DSO stuff is in preparation for hardware acceleration. This can only be a good thing.

The argument about getting different results could be used for different CPU's too. In reality this stuff tends to be implemented by the renderer if it's that important (eg random numbers), and should drop to software seamlessly. I also expect most places have reasonably homogenious networks.


How can you know that they don't just triangluate any polygons adjacent to any triangle, use Loop on that subnet, then lineraly blend with the result of CC? Do you have PRMan source code at hand??? ;)


You'd better ask Julian (levork) - I think he probably does!


Inline archives (that allow a true 'object instances') exist since years in the RI. What are you talking about? You can create an entire attribute state inside an inline archive and instance that. Thr spec is not clear what happens if an inline archive handle gets redefined but a sensitive thing would probably be to overwrite. From that pov, the RI is largely IPR ready since years.

<snipped..>

I find it intersting that features people deem so important in some contexts (IPR) actually aren't at all when one looks at the real world(tm).


Instance arachives aren't instances in the true sense of the word as they do no share memory. - they just share the RI calls. This means that you save network traffic and hits to disk and can still change stuff from inheritted attributes etc when it is called.

I'd disagree that IPR is not important. People don't use it in the real world if they are rendering with RenderMan as there isn't a really good way of doing it.

Pixar has invested a lot in it's lpics tools for interactive lighting and this is definitely an important area that needs addressing.

Don't get me wrong - I am an ardent RenderMan supporter, but I am not going to pretend that it doesn't have problems which Mental Ray does better.

Simon

[Sifis]

You all forgot to mention that the new final gather algorythme doesn't suffer from flickering any more even at the strict 3.4 mode.I was able to test it with a 150 frames animation with deformations and it renderd a beautiful flickering free FG animation with only 100 FG rays while the same animation with Maya 7 and mental ray 3.4 was suffering from flickering a lot
using exactly the same settings.So for me that feauture only worth the wait..

[wurp]

about time, FG has been totally useless for animations because of this for a long time now, glad to see they are finally getting this sorted, it looks as if I could start using FG in production once the new mr is out..



You all forgot to mention that the new final gather algorythme doesn't suffer from flickering any more even at the strict 3.4 mode.I was able to test it with a 150 frames animation with deformations and it renderd a beautiful flickering free FG animation with only 100 FG rays while the same animation with Maya 7 and mental ray 3.4 was suffering from flickering a lot
using exactly the same settings.So for me that feauture only worth the wait..

[playmesumch00ns]

Bloody hell. Who'd have thought that a couple of new features would cause such an argument??

I don't care. I've decided we're going to render the next couple of shows in POV-Ray :)

[gga]

Hmm, that's why mray gets sds support now. And don't answer with mental matter. Too few users to be production ready for VFX plus has the shortcomings other people mentioned before.

Like I also mentioned, some places and software may have or can develop their own subd code, as the geoshader api has allowed adding new geometry types relatively easily since v2.1 or so and mray has had top notch bspline and nurbs code since v1.9, so a subd scheme like doo sabin or CC can be implemented easily.
Too few users? I assume you are talking about mental ray+mental matter, because mental ray itself is used in 3 of the most used animation packages, the most used engineering package, the most popular design package, and the most popular architectural packages. It is also used in several production houses, large and small, in all areas (film, commercials, games, architecture and engineering). I mean... how *many* users do you actually need?(!) I think the last thing that mental ray lacks these days is users.
The case of mental ray + mental matter probably does narrow the user base to maya users. mental matter is mray's official subd implementation. It supports an algorithm that is better than CC and one that is worse, but more CC like. It's been in maya since v5.0, roughly for 3 years (albeit uvs were indeed probably fixed on a later version. Poor artists at ESC did suffer thru bad uv issues). Now, you get a true CC algorithm.

I was suprised it took Pixar so long to see the light with all the subdivision schemes already implemenbted as operators or commands for polygon modeling in other 3d programs (Max) or for rendering (Lighwave's MetaNURBs).

Not sure I follow you. Catmull and Clark pioneered CC subds in 1978 (together with Doo and Sabin for the Doo-Sabin scheme). Yet, CC subdivision did not indeed appear in Prman until 2 decades later. Why it took so long is probably a question for someone at Pixar to answer, not me. Or did you mean mental images instead of Pixar?

You still didn't get my point. I'm talking about the difference of interpolating a tuple of arbitrary dimensions vs. single data. Aka interpolating uv[2] vs. interpolating u, then v, in all three cases using a case-sensitive (e.g. considering borders etc.) version of the resp. subdivison scheme.

No, I do get it. u and v can still be interpolated separately. There is no difference between a tuple, triple, or whatever. In fact, if you were familiar with the mental ray api, you would know that uv data is usually stored and interpolated as a 3 component vector.
Regardless, the only thing your algorithm needs to know is how the "uv mesh" so to speak of is connected. You can then see your subdivision code as a black box that just subdivides per-face-per-vertex data (i like to think of it as per-edge) data... with data being anything: points, uvs, floats.
In the case of mental ray, Lightwave, etc. this is both simpler than how this is handled in a Renderman renderer, since those former packages allow assigning different materials in each face. So, in order to find the "hard edges" of your uv, you can simply check the particular material assigned to a face and tag the corresponding uv vertices as hard, before you send your uvs to your subdivision "black box".
To do the same with ribs, you need to split your subd in several pieces and "stitch" them.

Then how long did it take you the first time and was that a production-proof solution?

I would be lying if I remember, but it might have been about three months. Spent two weeks first researching it both on the net and also in the library. The first month and a half was spent writing a Softimage plugin and investigating different subd algorithms (doo sabin, catmull, etc) and the other month and half might have been porting the code to a geometry shader.
The issue of uvs never came up as they were, foolishly, interpolated linearly up to a certain level of subdivision (usually, the same level of subd that the subd had been turned into a mesh and painted on, as no paint package supported subds).
I also do remember having had independently derived two of the vertex crease rules by the time Pixar's 97 paper was published and I had implemented Peters 92 and 94 algorithm (albeit I think I got only '94 working perfectly), so Doo Sabin (degree 2 surfaces) could be rendered with patches.
The plugin/shader was used in one commercial and one movie (two far-away shots), and yes, the code was indeed horrible. If you defined production-proof as something that was used in production successfully, then yes. If you defined production-proof as code that would work for years to come, then no.
The other issue at the time, besides my code, was that mray was at v2.1 and still did not have their geometry cache implemented, so the tesselation was always kept in memory. This made the stuff only good for commercials, but not movies.

You seem to know the RI more well than the average TD, I give you that, but stating that RIB files are binary is bollocks.

Mauritius, are you pulling my leg? What do you think RIB stands for? It stands for Renderman Interface Bytestream.
For someone that knows the RISpec better than me according to your own words, you just said something very funny.
For more information, refer to Appendix C of the Prman documentation, particularly the first line of the section entitled "RIB Binding". If you don't have access to Prman, you can download the free demo of renderman for maya and you can then access their docs on Pixar's webserver, like I did to make sure I am not telling you bulls*it.
RIBs have two versions of them: a 100% ascii representation and a tokenized, binary representation, where each RI* call is mapped to a token. This is used mainly for speed, as binary ribs are unreadable (unlike a binary .mi file) and require translation thru catrib or similar.

Also, RIBs, while supporting a hierarchical attribute state don't force you to use that

Sadly, it does force you to. Attributes and lights are always propagated hierarchically. Even if you flatten your scene, those two elements are always propagated "downwards" in the hierarchy, never upwards, unlike what the mray api can do. RIResource now in prman12 tries to finally work around that limitation, but still very poorly, imo.

And lastly, there's no need to use RIBs at all, you can send data directly to the renderer in many implementations using a RiBegin(NULL).

And like I already told you, that won't help you. All C Ri* calls are just a direct mapping to their RIB counterparts, just like all mi_api_* calls in mray have a direct mapping to the .mi2 syntax. That won't improve the api, only the speed of translation.

My bold guess is that your main exposure has been during your days at ILM in whatever pipeline they had at that time.

Your guess would be wrong. First time I encountered the RISpec was at Digital Domain back in 1996. At that point, RIBs did not support rib archives, hair, raytracing, etc. Translation back then was done thru Houdini and an in-house tool that did look more like the sed hacks you described.

If the Gelato guys had come up with st. that really kicked the RI spec's ass, I'd probably have taken the time to write a Pyg/GSL to RI/SL binding.

Giving credit where it is due, Gelato actually *did* improve upon the RISpec in two areas: it allowed shading networks in its scene description and, if IIRC, the RIB stack, albeit it was not fully gone, was used less than in RIBs (my memory is a tad fuzzy about it, thou).

I never heard that before. Could you state in which way the mray's API is better at describing any of these tasks?

I can do something better, like show you :) You are already aware of my converter.
If you are lazy or don't have mray available to you, just visit: http://www.putfile.com/gga73/media
The two coolest videos are gone, but there's still some left.

Why is that? You can make your "world" an inline archive, describe all maps (textures, shaow-, environment-, photon maps, etc. etc.) in one RIB and that spits out this data, then renders it.

Yes... but there are a lot of things in the RISpec that won't map very well to IPR. Anyway, if you don't believe me, go ahead and try to get an IPR going.

That's not such a flaw, look at the solution the Gelato guys came up with. Their API might be debatable, but the possibility is there by plain allowing to link any parameter of a shader with any output class parameter of any other shader. Similarly implemented in the RMan compliant Aqsis renderer with a new RI call btw.

I'm aware of both. But what you are saying is 100% contradictory. If lack of shading networks was not a flaw, why would Larry Gritz (ex-chief architect of Prman for 10 years) add support for that in his new renderer?

You can use a shader tree building tool like Houdini, Slim or ShaderMan to build your trees, then generate a very optimized shader from that.

The shaders are actually not very optimized, as all those just concatenate .sl code and there's a lot of unneeded temporary variables.
That being said, you should *theoretically* get something that is more optimized than phenomena. But there are also a lot of other tradebacks you get for doing that.
Best approach is to have something like phenomena for look development and the ability to collapse the shaders like what you mention for running shots. mental ray provides the former, RSL provides the later. The collapsing of shaders in mray won't happen until mental mill. I'm not aware if Pixar will develop an equivalent to phenomena.

Besides, the RI spec makes explicit reference to Cook's famous "Shade Trees" paper, so the authors were well aware of their choice -- it was an intentional one.

Maybe. Did you actually ever read that paper? Contrary to its title, it does not describe shading trees as artists know them today, but it is more of a description of prman's rsl. Not knowing Cook, I don't know if it was indeed a choice he made or it was more a choice made due to the state of technology at the time. Back then, people would hard-code materials in renders and nothing else. And a C compiler was something VERY expensive, so you could not give that to your artists. A domain-specific language that used its own compiler was just a smart idea which solved both problems.
The idea of an artist-friendly gui was probably something that nobody had conceived at that point (TDI was, afaik, the first software to move in that direction).
Cook's brilliance was not so much in coming up with shading trees, but in implementing that language as a SIMD machine, which fit perfectly with the work that Catmull and Carpenter had been doing with the REYES algorithm.

But talking of flaws, the big problem is the lack of strctured user data (structs).

Really? I consider the lack of structs a problem in prman but mainly for their shading language, not so much the scene description. One of the things that always seemed really silly about the renderman api was that, although many of their built-in commands support optional key->value options, that feature was never exposed to user functions.
So, you can have:
texture( "...", "swidth", 2.0, ... ); // swidth = 2 being optional

but you cannot have:

float myfunc( color Ci, float swidth = 1.0, float twidth = 1.0 )
{
}

myfunc( Ci, "swidth", 2.0 );

You just have to keep remembering the position of your parameters, like C.
Even with that added, you still have the problem that your functions can get huge with the number of parameters.
And that's where classes, NOT structs, are useful.
In mray, you can do something like:

float myfunc( color& c, myfunc_params& p )
{
}

myfunc_params params;
params.swidth = 2.0f;
myfunc( c, params );

And let the myfunc_params' constructor deal with the default settings. Also, if myfunc_params adds a new option, all my function code does not need to be modified, unlike rsl.

That's a minor area where RSL clearly shows its age and its C roots, as those two features are now available on almost every popular scripting language, too. C++ has supported classes all its life, albeit no parameter naming in function invokations.

Hardware acceleration meaning what?

Hardware acceleration meaning you can take advantage of Cg, and potentially HLSL and ArtVPS api to take advantage of scanline rendering/raytracing acceleration.
Its use in games is now unavoidable and its use for IPR also.
I did not attend siggraph, but, as far as I can tell, the renderman notes just describe a Cg hardware shader (for maya?), but not for prman.
Doing hardware acceleration thru a DSO can now potentially be done in prman13 thanks to their grid shadeops, but *you* have to take care of sending each grid of polygons to the graphics card. Assuming every 4 points corresponds to a micropolygon, you still only get a single grid to work on, so you either have to cache all the grids (and take a big memory hit) or send each grid of points to the GPU and continuous derivatives across shading grids be damned, then :) And let's not talk about lights. How do you pass lights to your hardware shader if the C api you deal with in a DSO does not give you access to them?
Thanks, but no thanks. That's the job of the renderer, not the shader writer. mray is still way ahead of the game here, sorry.


With CC I'm sure I can convert that into a net of connected b-spline patches then do fancy stuff with that before I render. With a Loop sds, I currently can't.

Actually, with CC you can't. CC only converts to a bspline on regular areas (meaning mray's subds using only quads). Irregular areas need to be handled specially, using Jos Stam's algorithm. If you use Peter's PCCM algorithm, you get NURBs everywhere, but the shape is very close but not quite CC either. Or you can use a recursive patching algorithm like described in Pixar's paper, but for animation that algorithm is not much use.
Currently, the only package I know that you can do what you say you can do is with maya, if you switch to their subd implementation (not polysmooth or any of that), which uses Stam's algorithm.
Other than that, you can just go to polygons at some subd level, but you can do that with any package and, relatively easily, with any algorithm.

How can you know that they don't just triangluate any polygons adjacent to any triangle, use Loop on that subnet, then lineraly blend with the result of CC?

I don't know. But if I recall correctly the old docs for it stated that a special subdivision rule was used to handle triangles. Nothing more.
It is also a common practice with subds. Zorin and Peters, for example, have used modified rules using cosines to basically flatten the ring of vertices around extraordinary points and thus get a "flat" and continuous area (at the cost of screwing up the shape of the surface a tad).


"hard edges" = "right" I'd call biased at best.

I call it previous art. Lightwave has done that since v3.5. No user ever complained. The pinching you get as a result is a clear indicative of a potential problem to the artist, without the need of a warning.

And speaking just of attributes -- you can name "resources" and instance them since PRMan 12.

Yes, it is a pretty bad hack, if you ask me. Without having tried it, my guess is that it probably won't scale that well. I can only imagine dealing with a Star-Wars-kind-of scene and having a resource for each object in the rib to try to implement ipr like that. Yuck.

Interestingly, my XSI to 3Delight exporter starts rendering an average complex scene much quicker than does XSI with mray even though they have shared memory scene database. I find t intersting that features people deem so important in some contexts (IPR) actually aren't at all when one looks at the real world(tm).

And how fast does it do IPR, compared to XSI? :)
Joke aside, considering that I have not tried your converter nor looked at how xsi does things these days, I cannot say for sure, as there could be a multitude of reasons that have little to do with having a shared memory database. Having a shared memory database should certainly not hurt you performance wise.

[gga]

I am using XSI and there doesn't appear to be such an option. There is an option to rebuild shadow maps, and OGL accelerting them, but no optiuon to name them.

You are probably better asking in some xsi newsgroup but, in general, if there is a rebuild shadow map option, I'd expect that shadow maps can be saved to disk. Maybe xsi gives a name to the shadow map automatically.
Your best bet is to set rebuild shadow maps off, set verbosity high and read the messages about shadow maps. During a normal beauty render, you should see the shadow map being created for the tile as render progresses. Once the beauty render finishes, you should see mental ray reset its percentage back to 0% and start a new render without displaying anything new but saving each shadow map. If you re-render the same frame or another render pass with rebuild off, you should NOT see any messages about shadow map creation.
Obviously, if you move a light, you should reset the rebuild shadow map option to on or the shadow map will not align properly (you'll be reading the old map).

[sacslacker]

I just realized something....

I'm dumb! :)

[scorpion007]

sorry for the silly question, but gga, which docs were you referring to when you said I could access them on Pixar's webserver upon downloading the Evaluation version of RfM?
I can't seem to find them?

[playmesumch00ns]

gga, I think most of the things you note in prman as limitations are being addressed.

For clarification:
1) The prman13 RslPlugin API lets you write functions that accept varying parameter lists, so you can do your own ( "swidth", 2.0, "makecool", 1 ) type parameter lists.

2) RIB can also be an arbitrary mix of ascii and binary, so you can have all your state calls in ascii, while your geo is described in binary.

I've never, ever had a problem with the heirachical graphics state. Personally I find this method of specification to make the most intuitive sense. I've never had cause to use the features that allow you to buck that model, so I can't comment on their efficacy.

As for hardware shading. I really don't care about that either. We have a large renderfarm, and there's no space for GPUs in there! If we ever did get to the point where all our blades are sporting quadros (which I'm sure we will, one day), I'd probably take a long look at gelato before i weighed up whether prman or mentalray's "implementations" were better.

The one thing I think you do have a point on is IPR. Again tho, it's only a matter of time. :)

[shingo]

Gonzalo,

What is your take on MetaSL and Mental Mill, and how will this benefit the end user? are you pleased with the implementtion?

[playmesumch00ns]

Is anyone even allowed to talk about that yet?

[pseudoE]

Is anyone even allowed to talk about that yet?

http://www.mentalimages.com/2_4_mentalmill/index.html

[dagon1978]

ehy gonzalo!
i'm not a programmer, so, i can't understand more then 1% of your words, but, thanx, you are very instructive ;)
i particularly like your efforts in the ipr way, i like ipr and i would love a good ipr working with GI too (fprime it's the best one i ever saw), you think it's possible to make it work with FG in the future?
i'm very excited for the new mr_liquid, hope you can complete it soon

thanx

mat

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.