RenderMan-compliant renderers - questions/licensing


#1

Hello everyone,
since ages I want to start learning and using a renderman-compliant renderer for production. I believe that just because of the fast dof, mblur, displacement-features and of coarse to solid passes, it would be the right choice for vfx-related projects. I’ve used Mental Ray quite some time and I was always happy up to the point when it came to rendering 3d-motion blur or using passes.
But now I’m having some other concerns. 3Delight seems to be locked to 4 threads when you buy the license for 1500$. There is no word about what happens when you are having a machine with 8 cores. Can you run two instances side by side when you shell out 3000$? Hardware is pretty cheap nowadays and you can build an 8-core-system for about 3000$ or less. I’m just having the feeling that the pricing is a bit steep for just the renderer. AIR seems a bit more reasonably priced, 750$ for 8-cores, but this doesnt include tweakAir and I still have to investigate if that’s a thing you really need. PRMan or RenderMan Studio seems out of question for a small shop, because it would cost about 7000$ for one 8-core-workstation.
Right now it seems like a big investment if you want to open you own shop and jump right on the renderman train… unless of course you go the opensource route with “Pixie”.
I know this discussion has already been there to some extend, but do you believe it is a good idea to use Pixie in its current state of development for production?
Sorry if this all sounds kind of newbish and the questions are so fuzzy - but my mind is right now kind of fuzzy when it comes to renderman. Of course I’m in also the process of finding the answers for myself. I’ve bought the book Essential Renderman and right now I’m typing away Rib-Files in my favourite text editor to render all kinds of colored balls with pixie :).
What kind of bothers me, because of demo limitatiations I can’t really compare the the speed of the different renderers, especially how fast the raytracing modules are and how well the renderers scale when using multiple threads.
The free 3Delight license has a limit of 2 threads, Air-Demo Version has a limit of one thread.
Right now AIR and Pixie sparked my interested the most just because of the pricing.
I would really be interested if anyone has incorporated Pixie in his pipeline for production and what kind of limitations or problems one can expect (stability?, solid passes?, raytracing speed?)

I hope someone can shed some light on some of my questions…

Many thanks

Greetings


#2

Having used AIR in production, I found it quite hassle free and the support guys are very responsive (haven’t dealt with them directly but the results and update were always quick).

As far as speed is concerned, I haven’t really tried 3delight to its full potential but it looks very promising. And all the people I’ve spoken to have very nice things to say about it. And its really a great tool to learn renderman. I haven’t used Pixie so I wouldn’t know how it fares when compared to 3delight which does have a production proven track record by the way.

-Sachin

p.s. haha, i was just downloading AIR 7’s trial version to check on the updates since I last used it (and that was over a year ago). Talk about coincidence. And yeah, I too would like to know if Tweak AIR is really of any help.


#3

As renderman user I find 3delight is great, the raytrace is fast and good and you have a powerfull renderer for a small production.

Pixie is free and develloped by stanford so they have lot of contact with Pixar and pixie has nice feature for a free renderman, the raytrace is good and the engine too, even for me free 3delight is a bit better to learn renderman.

Air is a good renderman compliant but many things are missing to me, they try to build a package like pixar did with rat and rms but it’s far away from pixar product. air is not really fast in raytracing but it’s cheaper.

Prman is expensive for 8 core for sure but Pixar offer unique feature and a great integration for everything, it’s a investment fo a small studio but a really good investment considering updates are cheaper each year for new version. considering that pixar is focus on VFX too because of their own movies and ILM partnership.

So for multithreading performance it depend about the scene, raytrace become really fast with big amount of geometry in a renderman. But I’m not sure those renderman could take advantage of a 8 core computer than a renderfarm.

And raytrace for reflection is not an obligation with the introduction of new point based reflection, you can see the result of this Prman technics in iron man and ratatouille. Now we can limit the raytrace as much as possible limiting the memory consumption and numbe of cpu to render frame in a relative render time.

For me you need to consider first what is your need for your production and choose the best tool for that. sometimes expensive software are a good investment because of the technology and tools they bring to speed up your deadline. think about it’s a one or two year investment.

so Prman is the most powerfull, customizable and advanced renderman but also the most expensive of course. including a nice renderserver with alfred. works with RMS too in maya. the leader in the industry.

3delight is a really nice and innovative renderman with good shadeop, and well implemented function, but not so powerfull and advanced as prman. the price is good for a small company. good compromise

Air is a nice renderman but not the best for production vfx ,too many features are missing but the price is nice for a company. not the best bet too me

Pixie is free and open source but not really advanced and slower than others but provide a good support of multithreading, raytrace, point based, pont cloud and brickmap. you can try it for fun but fo production it’s not the best choice.


#4
       ...and for big productions as well. Check the [Wikipedia page on 3Delight](http://en.wikipedia.org/wiki/3Delight) to see a list of movie credits.

Pixie is free and develloped by stanford so they have lot of contact with Pixar

       Hmm, if anything, Pixar would probably be happy if Pixie disappeared tomorrow. Because if you run some RIBs that make heavy use of ray-tracing or GI trought both PRMan & Pixie, the latter is close enough to make the former look bad, given it's price tag.

Air is a good renderman compliant but many things are missing to me, they try to build a package like pixar did with rat and rms but it’s far away from pixar product. air is not really fast in raytracing but it’s cheaper.

       AIR has fast ray-tracing. I don't know where you get your opinion from. Can you post a RIB & shaders where AIR performs badly for this feature?

Prman is expensive for 8 core for sure but Pixar offer unique feature

       What unique feature(s) are you talking about? 

it’s a investment fo a small studio but a really good investment considering updates are cheaper each year for new version. considering that pixar is focus on VFX too because of their own movies and ILM partnership.

       Every one who works in VFX and uses PRMan will tell you that this is were Pixar really needs to do their homework better in comparison to other products (particularly 3Delight & AIR).
       Image based lighting support? We have to convolve every image "by hand" where I work because we use PRMan.
       Working subsurface scattering? Not in there and not coming from what I see (the place I work at is just developing their own subsurface DSO shadeop, [like other places in London have done](http://research.edm.uhasselt.be/%7Etmertens/papers/cheap_bssrdf.pdf) before to circumvent the issues with this "feature" of PRMan).

raytrace become really fast with big amount of geometry in a renderman.

       My experience at work is to the contrary.
       Try a really complex scene and it uses too much memory.
        Last year, I wrote a RenderMan displacement baking utility that uses ray-tracing and was meant to be used with PRMan.
        We ended up baking all the maps in 3Delight because PRMan couldn't do it within the 16GB our workstations/render blades have. 
       
       3Delight used under 9GB, same number of threads (4), same RIB, same shaders.

And raytrace for reflection is not an obligation with the introduction of new point based reflection,

       Yes and no. You only get away with it for really fuzzy stuff.
       All second order reflection will be wrong if you use point-based techniques. For shiny chrome objects that move slowly, you can't use it at all.
       
       Speaking of which: PRMan is still slow on any raw ray tracing. The only way you can get to trace faster is by using the irradiance cache. But that only works for fuzzy stuff (which is now better handled by point clouds/brick maps anyway).

Now we can limit the raytrace as much as possible limiting the memory consumption and numbe of cpu to render frame in a relative render time.

       Limit memory consumption with point clouds in PRMan? :drool:
       
       You realize PRMan loads point clouds when the shader asks for them and they stay in memory for the rest of the frame!? This "kown limitation" (Pixar) has given us a lot of trouble on my sequence on "Hellboy II".
       
       3Delight's point clouds are stored with a spatial datastructure that allows them to be loaded lazily into a cache. When the cache overflows, least accessed voxels get purged. 3Delight has had this since they introduced point clouds, over two years ago. PRMan ... nada.
       
Of course, PRMan does do this for brick maps. Brick maps, however, (still) suffer from interpolation artifacts in this renderer which is why people currently prefer point clouds (that then give them memory issues).
       The next PRMan version will probably adress a lot of this but it is not out yet and this has been a problem for years now.

so Prman is the most powerfull, customizable and advanced renderman but also the most expensive of course. including a nice renderserver with alfred. works with RMS too in maya. the leader in the industry.

       You keep stating that at CGTalk, but repeating bollocks time and again doesn't make it true.

       How is it more "powerful"? What do you refer to by "powerful" anyway?
       How is it more customizable? More customizable than what? Mental ray is more customizable than PRMan. What does that say? Nohing really.

       What is nice about Alfred? Tell me one thing and I can reply with ten that are "not nice" (to use a bold understatement). Just as I write this I'm waiting for Alfred to come back after it kicked the bucket -- so I can submit my renders and go to the pub!
       
       "The leader in the industry"? Can you please post a single production RIB & shaders that shows PRMan outperforming 3Delight to back up your funny claims.
       
       In every comparison between PRMan and 3Delight I did at work in the last 12 months, using actual production RIBs and same shaders from the very show I'm working on, PMan came out second.
I'd tend to think that "second" and "leader" are two terms that don't go too well together.

3delight is a really nice and innovative renderman with good shadeop, and well implemented function, but not so powerfull and advanced as prman. the price is good for a small company. good compromise

How is 3Delight less powerful than PRMan?
How is PRMan more advanced than 3Delight?
       Where's the compromise? What shadeop(s) (features) do you deem missing in 3Delight?
       
       Can you post a single -- just a single -- example to back up these statements that you repeatedly make at CGTalk about PRMan vs the rest?

Air is a nice renderman but not the best for production vfx ,too many features are missing but the price is nice for a company. not the best bet too me

       What features are specifically missing in AIR?
       You realise that some of the greatest digital visual effects were done with a PRMan version that had a feature set not even equalling that of Aqsis nowadays ("Jurassic Park", "Terminator II", "The Mask", etc. etc.).

Pixie is free and open source but not really advanced and slower than others but provide a good support of multithreading, raytrace, point based, pont cloud and brickmap. you can try it for fun but fo production it’s not the best choice.

       "Not really advanced"? You are always quick with blurry accusations. What is not really advanced enough in Pixie?
Slower? What speeds did you compare? Not long ago Pixie even kicked PRMan's ass when it came to ray-tracing.
       
       I frankly think that you never ever used anything but PRMan in production. I'm not even sure if you ever even used PRMan in production given some of the statements you made.
       
       I can't help but conclude that you shouldn't afford an opinion at all on how RMan-compliant renderers compare.
       
       I used pretty much ever RMan-compliant renderer out there in the last 13 years.
       I used most of them in real world productions. 99% of what you say misses the mark so much, I wonder if it was worth my reply debunking it.
       
       
       Cheers,
       
       Moritz

#5
  This has nothing to do with RMan-compliance but with an algorithm called "REYES". Houdini's Mantra renderer e.g. has all these features as well but isn't RMan-compliant. But it too is a REYES renderer of some sort.

But now I’m having some other concerns. 3Delight seems to be locked to 4 threads when you buy the license for 1500$. There is no word about what happens when you are having a machine with 8 cores. Can you run two instances side by side when you shell out 3000$?

  Yes you can. Or you can then run a single instance using 8 threads to make better use of your memory.

Hardware is pretty cheap nowadays and you can build an 8-core-system for about 3000$ or less. I’m just having the feeling that the pricing is a bit steep for just the renderer.

  Well, PRMan is $7,000 for 8 cores. PRMan is the product 3Delight competes with.
  3Delight is faster than PRMan and uses less memory. So it is much cheaper than even  3/7th of PRMan's price.

From personal experience using both renderers in production and how each vendor handles bug fixes & feature requests, I would also think that cost of ownership is a lot lower for 3Delight. With “cost of ownership” I refer to the money you spend (directly or indrectly, e.g. working around bugs) after you bought the license and ignoring yearly maintenance fees.

One must not forget the markets where these renderers are used and compete. Big places buy hundreds of licenses and the licensing for this sort of renderers has always been based on CPUs in the past 20 odd years.
I think this will change in the future (maybe price will be based on MFlops or the like) but currently is still is as it is.

Finally, if I look at what companies charge for 10 secs of VFX these days, 1,500 quid doesn’t seem all too steep to me.

AIR seems a bit more reasonably priced, 750$ for 8-cores, but this doesnt include tweakAir and I still have to investigate if that’s a thing you really need. PRMan or RenderMan Studio seems out of question for a small shop, because it would cost about 7000$ for one 8-core-workstation.

  AIR isn't directly competing with PRMan. Among other reasons also because it is not a REYES renderer. Sitexgraphics also doesn't make as much effort to keep AIR in sync with PRMan as does DNA.

Right now it seems like a big investment if you want to open you own shop and jump right on the renderman train… unless of course you go the opensource route with “Pixie”.

  Pixie is a great renderer. Unfortunately, one of its main developers, George Harker, got recently hired by Pixar to work on PRMan. So he'll not work on Pixie for a long time (or ever again).
  
  Not many people know this, but Pixie has been used on some pretty big shows alongside e.g. PRMan. Since most of these renderers use TIFF files for textures/shadow/environment maps, you can e.g. use Pixie to render your shadow maps, then use them with 3Delight or PRMan. This gives you unlimited free licenses for a lot of stuff that would otherwise lock expensive seats of the resp. commercial renderers.
  
  Pixie has also become much more stable in recent years. I would definitely give it a shot but you need to be prepared to give lots of feedback to the developers and wait for bugfixes until they get the time to attend to them. That's the difference between a free product and an OSS one.
  
  If you use AIR or 3Delight, bugfixes will be very fast (less than a day in case of 3Delight). 

Pixar usually rolls outs fixes with patch releases regularly but sparsely.
For example, between RenderMan 13.5 and 14, there are only 4 patch releases (in 12 months). If you are affected by a bug fixed in the next patch, you have to wait until Pixar releases that. 3Delight & AIR give you patches releases instantly.

I know this discussion has already been there to some extend, but do you believe it is a good idea to use Pixie in its current state of development for production?

  Depends. I wouldn't dare it for time-critical stuff (e.g, a commercial with a timeframe of a few weeks).
  But if it was a longer term project, e.g. 6 months, I'd certainly consider it. Also because I can always render elements or frames that give me trouble with another RMan compliant renderer. :)

What kind of bothers me, because of demo limitatiations I can’t really compare the the speed of the different renderers, especially how fast the raytracing modules are and how well the renderers scale when using multiple threads.

  You can compare with 3Delight w/o a problem -- if you deactivate the license, it will use all CPUs/cores of your machine (but render with a watermark). Only when the license server is running, for the free license, it will be limited to two threads (and not have a watermark).
  Since you're interested in speed/memory, the watermark shouldn't matter. :)
  
  3Delight 7.0 scales very well, speed and memory wise. PRMan 13.5 scales slightly better speed wise, but awfully, memory wise.
  However, you can make 3Delight scale bad, memory-wise, as well by using multi-processing. Doing which makes it is again faster than PRMan (using about the same memory).
  
  As far as 3Delight 7.5 vs PRMan 14 goes, I can't give any details here because of NDAs.
  
  Lets say you will likely be very positively suprised if you're siding with the underdog. ;)
  I say "likely" only because my base of comparison is beta versions of both renderers but I really don't expect vast changes here before SIGGRAPH when they'll probably be nearing a release each.

The free 3Delight license has a limit of 2 threads,

  Yes, but this is nevertheless a full blown license. You can do commercial work with this. Imho 3Delight is the best renderer for VFX work money can buy at this time. Getting a 2 thread licenses of this for free is very generous.
  
  3Delight does kick PRMan's ass and has pretty much the same feature set. [There are some things PRMan has that 3Delight hasn't and some things 3Delight has that PRMan hasn't](http://forums.cgsociety.org/showpost.php?p=4705072&postcount=3). 
  
  But all in all, the renderers are pretty much the same for 99% of the features that people really rely on, in production.

Air-Demo Version has a limit of one thread.

  And it's a demo, so you can't do commercial work with it.
  
  
  Cheers,
  
  Moritz

#6

pixlix2 , you could also look at using Houdini and Mantra which is extremely powerful.


#7

well with our experience we have develloped a lot of DSO plugins and tool for Prman, we add lot of difficulties to run some of our dso and tool in 3delight, even massive is really easy to use in prman for us.

implicit surface and plugins fluid are a lot better in Prman, we had lot of problems with 3delight test.

Prman offer new feature not provided by 3delight. including point cloud and brickmap ( I know point cloud are structured in 3delight , but now it’s also the case in Prman 14.) Prman offer new rsl shading language with co shader and all that. maybe you don’t use it but we use it a lot and specially for relighting engine. DSO are multithreaded in simd process in prman. the raytracer is slow in Prman that’s why we created a custom raytracer which is faster.
The powerfull array included in rsl in Prman is very usefull and powerfull. you have a lot of features unavailable in 3delight. about point based the point based occlusion and color bleeding have a lot more option in prman to control, and the photon diffusion from point cloud is a unavailabled feature of 3delight, right?

I can’t detail all difference in prman you can check the doc from Prman and watch the doc of 3delight. I know many things are undocumented in both of them but all of my friends using renderman for years at ILM, or imageworks or pixar and much more company loves Prman instead of 3delight. maybe it’s because you use mainly the 3delight advantage in your production and not a custom pipeline who need lot of coding and DSO and this flexibility.

one of our teammate worked before with 3delight and he was a big fan of it but now he prefer Prman too even if 3delight is a really great renderer, for me it’s one of the best choice for a small production pipeline depend just on the need. if you want a deep API support Prman offer a lot of things that 3delight can’t do.


#8
              What difficulties? The company were I currently work uses a lot of DSOs. Both (RSL) shadeop(s) (plugins) as well well as procedural primitive ones. This company also only uses PRMan (and hence the entire pipeline is designed around it). Nevertheless I can render any RIB depending on all these DSOs with 3Delight w/o a problem.

implicit surface and plugins fluid are a lot better in Prman, we had lot of problems with 3delight test.

              As 3Delight does't support implicit fields plugins, I'm surprised that you manage to test this.  ;)

Prman offer new feature not provided by 3delight. including point cloud and brickmap ( I know point cloud are structured in 3delight , but now it’s also the case in Prman 14.)

             Careful, you are breaking your NDA here and Pixar is watching this board. :p
             
             Firstly, PRMan 14 isn't available as we are debating this. Maybe 3Delight 7.5 will have all features of PRMan that it currently hasn't (including implicit field plugins). Who knows? We should stick to the facts at hand about products available for purchase at this point in time, not the future.
            
         3Delight has brick maps as well. And yes, their point clouds have been stored in spatiall data-structure with lazy loading support from the beginning (i.e. their first implementation) ...

Prman offer new rsl shading language with co shader and all that. maybe you don’t use it but we use it a lot and specially for relighting engine.

              Yes, co-shaders are nice but they were also overdue. If the RI spec was run by an open group instead of being a dead horse, more or less, something like co-shaders would have been added years ago.
              
              I would also think there is a lot of problems with Pixar's current co-shader implementation. For starters, the co-shader handle list is global (co-shader handles need to be unique). Really a bad design mistake imho.
              Co-shader handles are strings. This should be a specific type for obvious reasons.
            There are also many bugs that get slowly fixed.
            
            Check the Pixar forums for a lot of the issues Pixar's implementation has (some stuff obviously only gets reported in the confidential forums for individual clients). Just for example, one of our TDs posted another problem last week about passing [i]this[/i] to a co-shader to allow reverse interrogation (from co-shader to calling shader).  This doesn't work.
              I would think that by the time Pixar has smoothed out all these issues (and co-shaders become actually set & stable enough to use them in real production), 3Delight will have them as well.
        
        And I'm also quite certain that when 3Delight adds co-shaders, their implementauion will not only be more solid (as in: suffering from less glitches, bugs and oversights) than Pixar's, but it will also allow for some obvious uses of co-shaders Pixar has missed so far.
        Missed not because they don't have enough bright people working there, but missed because of the rushed introduction of half-baked features into PRMan lately.
            
            A rhetorical question about this in light of the debate at hand: [i]PRMan did not support co-shaders between its initial release in 1989 and late 2007[/i]. How did you ever get something done before August 2007 if you depend on them so much that you actually list them as a reason to use PRMan over 3Delight? :)
              
            [left]I recall a time when any PRMan release Pixar put out contained primarily new features Pixar had been using (and thus testing & improving) in-house, on their own shows, for at least a year.
            [/left]
              These days it seems as if Pixar implemented features and released them straight away to their clients.
             
              Unfortunately it also appears as if their level of excellence in design of new features and the general QA in software development doesn't live up to such a fast-paced developement & release cycle. I really think that it would be much better for PRMan, as a product, if Pixar went back to their previous, slower development model. The hindrance here might be that in recent years PRMan has actually come under heavy fire from the competition ... 
             
             I was scared when Pixar announced that they wanted to increase the pace even more. At  the London RMan user group meeting last fall, Pixar actually said that they would try to release PRMan 14 much earlier and have a beta ready by the end of January. Luckily (for the quality of their product), they didn't keep that schedule.
              
              There was a time, not many years ago, when people would say that the difference between using the latest PRMan release and the latest mental ray release was mainly that. PRMan was rock solid, mental ray's lates features needed to "settle" for a year before they were ready for prime time. These days I'm not so sure this distinction still applies.
              
              Lots of features added to PRMan in recent years were like bananas -- they ripended at the client's side and the latter party had to bear the grunt of dealing with the implications.
              Prominent examples are:     

[ul]
[li]Point clouds (not spatially loaded, issues persists since they got introduced over 3 years ago)[/li][li]Brick maps (suffer from interpolation artifacts since they got introduced 3 years ago. a “fix” was rolled out in PRMan 13.5 in late 2007 but there are still visible artefacts in some circumstances)[/li][li]subsurface scattering (prone to artifacts if diffuse mean free path is smaller than shading rate, implications are insane point cloud sizes and slow processing – almost unsuable for look dev & production for these reasons. These issues exist since almost 3 years and it doesn’t look like they will be fixed in PRMan 14).[/li][li]Co-shaders & shader classes are the latest “problem child”. Great as a feature & much needed indeed. But they feel like they would have required some time “to ripen” at Pixar, before they were ready “to pluck” …[/li][/ul]There are regularly QA issues. PRMan 13.5.2 made our entire farm go tits up when we rolled it out one cursed Friday. We lost almost one day of render time for all affected shows (300 people at least) and went straight back to 13.5.1 on Saturday.

             I also think not many people actually test  the latest PRMan even against the previous version. It took someone from MPC almost [i]five months[/i], from the release of PRMan 13.5, to realize that Pixar had totally fuc5ed up the AOV sampling code in 13.5.
            The result was an [i]up to 400% increase in render time[/i] for one of the most used features in film VFX production with this renderer. Check the Pixar forum for the thread called "Additional AOV's take longer in prman 13.5 than in 13.0.4"[b]. [/b]The absolute effect on our own renders here was just below 300%, at the time.
             
             In other words: there were all these big VFX houses around the world (including the company I work for) that for months got roughly 300% increased render times with AOVs, after updating to PRMan 13.5. And only one company noticed, and even they took 6 months to do so!!!
             If people have that much transparency on how the renderer they use every day performs, from version to version, I can deduce that they have probably zero base of comparison for how well (or bad) it performs, compared to any other renderer (e.g. 3Delight).

DSO are multithreaded in simd process in prman. the raytracer is slow in Prman that’s why we created a custom raytracer which is faster.

              So you're saying that instead of using something better (e.g. 3Delight), you wrote a way around it. That will make Pixar happy. Not only do you throw money at them for a renderer that partly isn't good enough for what you need it to do, you also spend more (of your own) money developing a custom solution around this issue. :)

The powerfull array included in rsl in Prman is very usefull and powerfull. you have a lot of features unavailable in 3delight.

              Even w/o using double positives desperately trying to disguise themselves as pleonasms, I can say: SL arrays indeed are available in 3Delight. :)
       
              Speaking of features unavailable in some renderer and available in the other: what about display subsets & exclusive displays? They are in 3Delight since years. PRMan can't even calculate the coverage (alpha) of an AOV in 2008.
              This is the most powerful feature from a production perspective I've seen added to any renderer since probably almost a decade. If I had to choose between that and e.g. co-shaders, I'd always choose the displays subsets.
              Where you have to render [i]n[/i] times in PRMan, I only have to render once in 3Delight.
             
             What about [i]working[/i] subsurface scattering?
             What about [i]fast[/i] ray-tracing (w/o writing your own ray-tracer)?
             What about [i]machine-language compiled[/i] shaders (gives you an instant free 40%-60% speed boost on volume shaders)
            What about a [i]network cache[/i] for RIB depedencies?
            What about [i]proper control[/i] over hair dicing?
            
            All this stuff isn't in PRMan but it is in 3Delight. And it doesn't make any difference. All that matters is that if either renderer has a feature that you desperately need and that one has but that the other hasn't, you need to buy a copy of the one that has.
            
            What really matters is the features that you use 99% of the time to do your bread an butter work. And as far as these go, PRMan & 3Delight are identical if we're talking about VFX work.

about point based the point based occlusion and color bleeding have a lot more option in prman to control

              What "control" do you mean?
              3Delight can run gather() on point clouds. This means I can do anything I can express in SL to filter point clouds or use them for actual shading.
            Not some black-box "ptfilter" uitility that has a lot more limitations than options (and there are a lot of options to ptfilter, indeed).
            
              I could e.g. write a new subsurface shadeop in 3Delight in SL using this gather() on a point cloud. Try doing that in PRMan w/o writing your own DSO.
       
              If you really think PRMan has more control over point clouds, you simply don't know enough about 3Delight (or probably most other RMan-compliant renderers) to make such a statement for starters.

, and the photon diffusion from point cloud is a unavailabled feature of 3delight, right?

              I'm not sure what you mean by photon diffusion. [Donner's & Jensen's paper from last year](http://graphics.ucsd.edu/%7Ehenrik/papers/photon_diffusion/)? I can't find anything about this in the PRMan 13.5 docs.

maybe it’s because you use mainly the 3delight advantage in your production and not a custom pipeline who need lot of coding and DSO and this flexibility.

              No, the company I work at these days uses solely PRMan.

one of our teammate worked before with 3delight and he was a big fan of it but now he prefer Prman too even if 3delight is a really great renderer

              Well, maybe your friend doesn't know enough about 3Delight. :) These are quantitative arguments anyway "My ma knows someonw who says watching TV causes cancer". For every TD you know that "converted" (whatver that means) from 3Delight to PRMan, I can give you the names and email adresses of four people that liked 3Delight better even though (or because of) using PRMan since years. But this really says nothing about the quality of either product, so we should not descend to such ways arguing. ;)

for me it’s one of the best choice for a small production pipeline depend just on the need. if you want a deep API support Prman offer a lot of things that 3delight can’t do.

              What "deep API"'s are you talking about? Rx? Rif? RSL plugins? They're all supported by 3Delight. These are the APIs most places use. Things that renderer X can't do?  Check some of the header files that come with 3Delight. Not every API they support is documented and some stuff in there will not be in PRMan in the forseeable future.

Furthermore, if you use 3Delight and there is anything missing, just ask. When I used 3Delight in Australia at Rising Sun Pictures for two years, there was not single feature we asked for that wasn’t implemented by DNA straight away. The absolute longest we ever waited for a feature was seven days. That was btw. the RiNuCurve() implementation which we needed to render the spider webs coming from the custom web-solver RSP developed for “Charlotte’s Web”.

You don’t get this level of support from Pixar. No one does. So if 3Delight doesn’t have feature X or Y, it really isn’t that much of an issue. The addtion of features to 3Dedelight is entirely customer demand-driven. If you buy a bunch of seats of 3Delight and need a feature (or an API exposed), they will add it, you just have to ask. Consider that when you use arguments like “doesn’t have X or doesn’t have Y”.

Mind you: I’m not saying PRMan is a bad renderer, quite to the contrary. All I’m arguing against is that there is any adavtage of using it over 3Delight, quite to the contrary so.

            To afford a honest opinion, you need to run actual production shots through both renderers. I don't know a single person apart from myself who is obseseed with the quality & capabilities of RMan-compliant renderers enough to do this -- particulalry using actual production shots. :)
                  
              And that is btw. the only reason I'm so outspoken about this subject matter.
             I think if you truly took the time to evaluate 3Delight as an alternative to PRMan in your pipeline, you'd see that it is currently the better one.
                        
      Of course, it is always best to have both renderers, if you can afford that.
            
            
              .mm

#9

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.